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
Move the HTML for the dialogs to separate template files,
using the template mechanism from core.
It is still possible to specify the HTML directly as before,
to be used in gadgets etc.
Change-Id: Ia7ad5aaa9cac429d1c9d706bdf6760e3eda358bc
Per T42972, the current hidesig implementation is broken, and only
hides the signature button in namespace 0 regardless of the value of
$wgContentNamespaces.
Seeing as the old implementation of hidesig was broken, I don't really
think backward compatibility with old configurations is a useful
concern here. In particular, hiding of the signature button is no longer
able to be configured in Special:Preferences (why such a trivial pref was
ever able to be exposed to users, I don't know).
Bug: T59727
Change-Id: I596fd435bc9be8c37da43177c1bea90ebff0b2fe
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
* Internal links: Show simple example first
* References: Show use of unnamed references
* Discussion: Use --~~~~ for consistency with what the toolbar button inserts
Bug: T26128
Change-Id: I08de0ad416727447eccad914c2ade3a93e5a8ae2
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
* Some users have reported that they did not like the new colour for the wirting. New colour changed back to black.
Author is Roul P
Compressed using https://compressor.io/compress
Change-Id: Ieda03d57197bc6c2dd0361e942a819732876ac36
Replace $.escapeRE from 'jquery.mwExtension' by
mw.RegExp.escape from 'mediawiki.RegExp'.
This change requires MediaWiki 1.26+
Bug: T103993
Change-Id: I5fc19e1313fc6a06726981e0365cea6d00abb5f3
* Re adds svg images that were reverted earler for causing problems.
* Adds some missing rtl svg images.
* Fixes insert-ilink.svg that was causing it to not show in some browsers eg internet explorer.
User Perhelion Fixed the problem in insert-ilink.svg and insert-signature.svg. I just added it to button-sprite.svg.
Related less file adding svg to it is at https://gerrit.wikimedia.org/r/#/c/195529/
Bug: T37342
Change-Id: I14482c7b66901609689bf9ddb67b8d2add937612
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
Using document.activeElement at the time of the unload
event as a proxy for whether the user is switching to VE.
Switching to VE is weighed more heavily than whether or not
the user made changes: switching to VE causes abort.type to be
'switchwithout' regardless of whether changes were made; only
if the user isn't switching to VE do we look at whether changes
were made and use 'abort' or 'nochange' as appropriate.
When wgAction === 'submit' (i.e. we're on a preview / show changes
view), it is assumed that the user has made changes.
Bug: T95938
Change-Id: Ic91b87c4fc5b601e1fd98b237100d808e97400bd
Needed because session IDs can be generated on the client
from the unload handler (when the back button is used).
Bug: T95919
Change-Id: Iac921bc36806205fc11ac76154ed8b3890f10d31
So that the ID isn't reused when the user uses the back button
to navigate back to an edit page.
It would be more natural to use pageshow for this, but that
event also fires on initial load. There is a .persisted property
that indicates whether the page was recycled, but that
property doesn't work in Chrome:
https://code.google.com/p/chromium/issues/detail?id=344507
Doing this from pagehide doesn't work either, because that
runs before unload (at least in Chrome) and causes the
abort event to be emitted with the new ID. So instead,
regenerate the ID in the unload handler after the
abort event has been sent.
Bug: T95919
Change-Id: I20a602a7896e75ffa116dcd2c137306ca84164b6
Some very weird issues going on involving multiple wikiEditor instances being
set up on the same textarea element. It's probably a race condition of some
sort and I'm hoping that restoring the modules like this will fix it.
Bug: T93384
Change-Id: I44c9c013993220ab709893d239614552d7b25d46
Seems to be causing errors on view (!) on plwiki, and I would not expect this
to work on non-wikitext pages.
Bug: T93242
Change-Id: I0336a85a2ab4bef1d20086382012047688ffa909
Also update the actual HTML with what the current parser outputs:
* width:104px -> width:102px (2px in addition to 100px image width)
* No more "title" attribute on the outer <a>.
And reduce duplication in the message:
* Re-use "thumbnail-more" message.
* Re-use "wikieditor-toolbar-help-content-file-caption" message.
Change-Id: I25f0763b2274ebdcf681c78af277a9be302350a1
If the WikiEditor is enabled for Semantic Forms Text Area Input there is
no license warning div around.
Change-Id: I8d39f8d47a73cdc2d4be198061e8f68f22c0c308
* Fix errors and warnings from phpcs.
* Add commas at end of lines for arrays in PHP.
* Add space between // and comment.
* Add space between ) and {.
* Use tabs instead of spaces for indenting.
* Break lines in PHP with more than 100 characters.
* Remove double spaces and spaces at end of line.
* Remove spaces before comma.
* Fix some typos.
Change-Id: I9c014bdfa9832fa6a20d0190fe2fc668983d0fb9
* This patch convert .css to .less
* Semantic changes are avoided, but there are minor
tweaks such as capitalization and ordering.
Change-Id: Iebff0f8e3d87bb792093a10d87f33540aca301d5
An early version of WikiEditor added a workaround for a reported
bug with IE 8 where textarea scroll and selection state was lost
when the contents were modified.
This doesn't seem to be needed on modern versions of IE such as 11
and above and the newer 'Edge' HTML engine mode in Windows 10.
Actually, I can't reproduce it in Windows 7 or XP with IE 8 either
from the original bugs, but just in case it's needed on some particular
version that we don't know about I've only added a check for modern
IEs, which is already in use on other old-IE workarounds in the
module.
Bug: T88875
Change-Id: I25b667a8d8378c417441adee5d97571c71a1c8c7
The search-replace box in WikiEditor was blacklisted entirely from
MSIE, although it appears to work fine in IE 11 on Windows 8.1
and Windows 10 Tech Preview.
IE/Spartan team specifically requested a fix for this bug; looks like
it's an easy case of adjusting the blacklist with a version component...
(Note that in RTL the dialog positioning is bad, but that affects
other WikiEditor dialogs too.)
Bug: T88875
Change-Id: I4cf1eb76cc8a788cab233fe9ed04aaeba4af5725
This changes the color of the line under the hader of the dialog boxes
from #6bc8f3 to the default #aed0ea.
This difference is nearly not recognizable and it is not worth to overwrite
the default color.
Change-Id: I88580ab74fc158ec1a498fc489fbdd9cd5ba897a
The only dialog with a table is the table creator dialog.
For this table a more specific definition exist in
jquery.wikiEditor.dialogs.config.css
These rules overwrite all here removed definitions except of
wikiEditor-toolbar-dialog table { margin-top: 0.75em; }
Without this definition the margin-top slightly increase to the
definition from .wikitable with margin-top: 1em.
Change-Id: I0aab246db05cb4330287666f6a71b56d6b88b0af
* Reflect that we're now calling mw.message( ... ).plain()
* Remove vague statement about "may eventually become a wrapper for
some kind of core MW functionality."
Change-Id: Ibe743162c1f72bb3977ec16e2ba4b023a66e3907
