When quickly clicking on a tab (the same one or a different one) in the
toolbar the new animation is started immediately even though previously
triggered animations might still be running. This leads to potential
issues as reported in T106993 bug report.
Make sure to stop previous animation first before issuing a new one.
Additionally 'resize' trigger is under racing conditions when
expanding/collapsing tabs, and needs to be invoked explicitly on any
size-change event (cannot rely on the fact that the last issued animation
will trigger last).
Bug: T106993
Change-Id: I874dd7cb9f2fe96e3a6493508cbae4de56f7a6c0
Since e8d37102 the loading spinner is not visible, because all actions
relating to it are in the same render step of the browser.
The loading occurs fast enough now, that we also don't want to show an
intermediate spinner.
Change-Id: Id2a3584deed2ecde807d8f354341dd6868b10009
Currently sections of the toolbar can be built deferred. This
is done for the help section and the special characters. The
disadvantage is, that you can't modify such sections before
they are really loaded.
This patch modifies the behavior by doing the following:
* Toolbars are always built directly. After all, deferring isn't
used there anyway in the standard configuration.
* When a booklet is requested to be built only when it's needed,
the index and all pages will be built immediately, only the
content of the pages is deferred and built only when it is
needed.
Even on slow machines building all pages immediately doesn't cause
noticeable pauses, in fact, opening a page with special characters
seems even faster because only the page you need is built, not all
pages.
Since all pages exist from beginning, you can remove and add pages
from user scripts. It is still not possible to modify an existing
page (add or remove a row to a help page, add or remove a character,
unless it is the page that was opened last time), but this is something
that shouldn't be needed very often, so it should be acceptable that
it still doesn't work.
Bug: T25479
Bug: T70791
Change-Id: I0e61b1fd4f6139a251e53a1fac28b3821bc6b860
The versions of Opera that this was targeting aren't really supported
anymore anyways. So let's just remove this hack.
Bug: T106574
Change-Id: I1b11fc8ec30f3c33b681daff7f676fa965fb78cb
When additional booklets are created, or existing removed, WikiEditor
currently stores one wrong cookie for each new booklet. This is because
twice a wrong id is passed as parameter, and because a cookie is set for
the default value. This patch fixes these issues.
Additionally I replaced in the function that needed to be edited a loose
comparison with a strict one ($.cookie will return null, never undefined),
and .size() by .length.
Bug: T27184
Change-Id: Iacc1c71a1e0fc2307a3a28d9c1bb00967ac9827a
Use mw.language.getFallbackLanguageChain() to get the
fallback language chain. This chain currently always contains 'en'
as last element. Remove the last element to prevent a fallback to 'en'.
Reimplement autoIconOrOffset to correctly prefer sprite before icon.
Bug: T87247
Change-Id: I452dd45d20ea4dd542d63274b7aad0272e20ea12
This patch replaces the manually operated test module for ext.wikiEditor.toolbar
with one based on QUnit. The new test suite uncovered a bug with the removeFromToolbar
API function in jquery.wikiEditor.toolbar, which prevented the removal of select buttons
from the toolbar. This issue has also been fixed in this commit. .jshintrc was updated
to ignore the new QUnit global.
Bug: T39485
Change-Id: Icef3debcffa484a8d78628bcd9da0892b750bb40
jQuery's show/hide/fadeIn/fadeOut methods makes changes to the
style attributes of elements. That makes them rather hard to override
their visibility, without adding an entire API to the module to do so.
This replaces the default animations with one using classes to control
visibility and only animates the animatable properties using
the style attributes.
Follow-up to: Iadaae3fb9ae1899e12605d653b2688616b8f7c40
Change-Id: I4652ade66c6de864ee3e74b3817ed9b93967ce3d
because apparently we do have empty tools boxes. Alternative
implementation in I4652ade66c6de864ee3e74b3817ed9b93967ce3d
This reverts commit dd46fc383b.
Change-Id: I358c34d63261989d49b0a4156cbc05b544727d5c
According to the jQuery documentation (and code) all kinds of
$( '<element>' )
$( '<element/>' )
$( '<element />' )
$( '<element></element>' )
are identical. So yes, this patch does not change anything. All it
does is removing characters that are ignored anyway. Using the same
style everywhere makes the code easier to read and understand and
may save a few bytes when it is gzipped.
The current WikiEditor code contains 67 usages of that jQuery call.
Only very few of them are not in the most simple <element> style.
Personally I consider the style <div/> confusing since a <div> can
not be a void element.
Change-Id: I816b4cccc9ee329e9bcdd9bd2353e5653fd10c36
This line forces sections to be visible after you edit the toolbar.
There is no apparent reason why this should be necessary. It has been
in there almost from the start, but doesn't seem to be used
Change-Id: Iadaae3fb9ae1899e12605d653b2688616b8f7c40
eqeqeq:
* Change loose comparisons to strict comparisons where
it seems safe to use a strict comparision instead.
Mostly comparisons to strings or objects, and comparisons to
numbers where the other value is known to be a number, too.
E.g. foo == 'string', bar == node, indexOf() != -1.
* Add eqeqeq:false to files where there are non-obvious usages
left.
onevar, quotmark:
* Disabled in files with lots of style violations.
unused:
* Remove unused variables that have no side-effects in their
assigned expression.
Coding style cleanups on affected lines where trivial.
Change-Id: I5db155a632740e24cb52dba2177c7fc35d5aebd5
Removed redundant attributes, added aria-* attributes and properly
declared the links with role=button.
Tested with JAWS 14 and NVDA.
Bug: 24592
Change-Id: I27e18798d18b63655ea716eee2be1c7ab5303759
The mix of <div> and <a> tags, being floated left inside a floated left
group seems to cause a flow error in some browsers, which ends up
wrapping the last item in the group. The give-away to what was going on
was that this only happened for groups with labels.
While diagnosing it, I notice that the bug did not occur if the labels
were hidden (suggesting is has something to do with the label being
included in the flow of the group, not the build-out), and converting
them to spans fixed the problem.
Bug: 27698
Change-Id: I2a842a86ef77a8934095c04408b7fabbcfbb2476
ClickTracking is deprecated; the config var gating this behavior is set
to false; the data is going to /dev/null; no one is interested in
analyzing it. I think it's dead, Jim.
Change-Id: I71ea8c174e5e38b28f128ccd380ed2a25ad50606
* This is similar to wikiEditor-toolbar-buildSection-*, but for when
all of the initial sections are done.
* It allows other code to render after this vertical shift is done.
Change-Id: I4705d09b9ef90c1ab8dad93db3f91e70c5fd4d5b
Right now, the Special Characters interface in WikiEditor shows all
characters in a monospace font which makes it especially difficult to
distinguish the different dash characters. The solution implemented
in this change is to add title tooltips to the following characters:
en dash, em dash, minus sign. The title tooltips are localizable and
can be added to any other characters as needed. If we eventually want
to add title tooltips to all the characters, we should come up with a
config shortcut like we're using for Hebrew vowels.
Change-Id: I7eb207acda045a868ec4c625c39bfd3d1f78ea17
To allow users navigating the text markup buttons by keyboard
the span tags have been replaced by anchor tags. Also a dummy
link target has been added to make sure screen readers recognize
these tags correctly.
Change-Id: I9ec1543f3a39b57452d72067cf85b11e9351f546
Will now check if character is defined and will return empty string as result instead.
Added a mw.log to catch this situation for developers.
Based on patch by User:Lupo.
Bug 31673
