This allows us to bundle the wgWikiEditorMagicWords and
mw.msg.wikiEditor(?!) config vars that were previously exported globally
in the startup module.
This code is old and crufty, so this is a somewhat minimal conversion:
* Use require() for jquery.wikiEditor.{dialogs,toolbar}.config.js,
and for jquery.wikiEditor.{dialogs,toolbar}.js
* Don't attempt to convert jquery.wikiEditor.js to something
require-based, instead just run it and let it set the $.wikiEditor and
$.fn.wikiEditor globals
* Consolidate ext.wikiEditor.{dialogs,toolbars}.js into
ext.wikiEditor.js
Bug: T222828
Change-Id: Ia75d685cbde786e8fceb6db36f2436b2beea1499
Similar to makecollapsible.. Played around with CSS transitions, but
due to the non-predictable and variant sizing of the section elements
isn't really worth the trouble in my opinion.
Also was an accessibility issue on the select (header) dropdown.
Bug: T210671
Bug: T175379
Change-Id: I6fa476645bae7f0e1b01c563c4395e2af003c2c5
CodeMirror forces WikiEditor to load. While CodeMirror handles readonly
textareas, the WikiEditor toolbar doesn't. CodeMirror and
syntaxhighlighting is pretty useful in readonly actually,
so I'm making WikiEditor a tad more resistent against readonly mode.
Bug: T188817
Change-Id: I927a780e1aea86a19750387f530bad84b1ff5ef4
The only use of raw HTML messages is in the help panel, which is the only user
of `layout: 'table'`, so we can replace all other callers.
Bug: T154891
Change-Id: I2df3ec8c05d4daaa094378354566356a822c081f
A new toggle tooltype which makes use of ToggleButtonWidget in order
to provide proper accessibility for all buttons that require on/off
state
Bug: T198781
Change-Id: I8b7fd41571a48fa4f6560790d94bb966972e740f
Replaces the insert and advanced-insert groups, which
are currently multi-colour icons.
Drops the button-sprite + offset mode, according to
mwgrep there are no other users of this.
Bug: T191031
Bug: T143508
Change-Id: I7032f98908a591ea5c9d3dbbb7616e2c10bbfc80
Make sure messages are escaped and not feed on raw html
before inserting into the group.
Also, updated the minus-x version to 0.3.0.
Bug: T154891
Change-Id: I12e5dc03396fa8bed9beb362ae91a77e64646113
> JQMIGRATE: jQuery.fn.bind() is deprecated
> JQMIGRATE: jQuery.fn.size() is deprecated; use the .length property
Note that bind() is not removed in v3, merely deprecated.
Even after the jQuery Migrate phase, it will continue to work.
size() was removed in v3 and works only during the Migrate phase.
https://api.jquery.com/size/https://api.jquery.com/bind/https://jquery.com/upgrade-guide/3.0/
Bug: T124742
Change-Id: I6bbd8f829ecf987228c6a5abd32c84e4e088a9bd
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
