This patch promotes a consistent design decision across projects in
MediaWiki core, extensions, and skins. The darker red color meets the
W3C Web Content Accessibility Guidelines (WCAG) at Level AA that text
or images of text must have a contrast ratio of at least 4.5:1 (or 3:1
for large text).
Bug: T343239
Change-Id: I517a8f5bee4f62267b37e66a8da7500ca547217e
1. The module always exists because this file is only
loaded from MobileFrontend.
2. If the module doesn't exist, mw.loader.using will
just reject anyway.
Change-Id: I6724078b362782813576cad2459e7b7903655e5e
The enrollment happens in ArticleTargetLoader so that the bucket will be
set for init logging.
Bug: T342930
Depends-On: I9c7c0fb52a6ec68609df6b518c7d35ddd98a95bf
Change-Id: I03c8dc8beb2eb267c052b856a30343ecab3a7657
Instead of inserting the editSwitch menu manually to the WikiEditor
toolbar, use the 'secondary' section which is already aligned to
the right.
Bug: T308423
Depends-On: Iff6d80628ebb5ec5685136fa02c2345eb5b49d42
Change-Id: Ic307f9dc7ad976862c8d8c6551ed29e6071f655f
As mentioned in the ticket access to this library is now
deprecated and consumers should require the module. The existing
method is replaced with the method in the migration table in the
Phabricator ticket.
Bug: T348807
Change-Id: I72a5242399d2cd04b5c9fbee947dc59d94c0ba7c
The URL parameter turns out to be a bit painful for people to use in
some situations.
Bug: T350749
Change-Id: I7c88dc604dd321a7c78810b21f7ad8306ff9dab6
Link is fixed by having the gallery image search results automatically
link to the image, which will resolve down to there being no `link=` in
the output. This lets us preserve whatever existing link has been
applied from source when editing gallery images later.
Follow-up to Iefc520b8513e833665dae9d5c3a9dca2762264a6
Bug: T350912
Change-Id: Iab21f72b7f1625d75fe52471b33718606c469518
I don't think it make sense to always fallback to the inital mode.
The wikipage.diff hook can be fired from 3rd parties to update the
diff. If the users then changes the mode inbetween without a page
reload, every following diff page update should have the latest
option as a default instead of the original option.
Bug: T346369
Change-Id: I2d0f6cbb89a2d98f247fcd77fa4d79708a4220c1
Since Parsoid now treats DEFAULTSORT like any other template, we have to
scan mw:Transclusion spans.
Bug: T337398
Change-Id: Icba92fc14c1c56ec4711ba49407e8be368d57842
In MediaWiki, OO.ui.getTeleportTarget() is overridden to return
a different element (itself attached to body), which is supposed
to be styled appropriately by skins (e.g. z-index above any
floating header, font-size same as body text, etc.).
As a result, we no longer need to do weird things with the
'vector-body' class to achieve correct font size on Vector,
and we can remove some font-size overrides for Vector and MonoBook.
Bug: T348288
Bug: T339058
Change-Id: I6329b3023573b3dcfc8f471c4693be9bb1e9e430
The wikitext table tool is re-using messages meant for other
things anyway, so might as well use a message that is still
in use elsewhere, as opposed to one for a tool that was removed
7 years ago (in Ife3f3505b845d).
Change-Id: I305f5f5a67e0340f89160e6654ad86f81609f9ab
Was lost when we converted it from a PopupTool
in I81d217bc1ab9.
Also visualeditor-help-title is unused since that commit,
and remove debugging code.
Change-Id: Ic1d40bac8ef76fbb6f009dd8cecec8dc74c1aa4b
Using 'mediawiki.skin.variables.less' with Codex tokens now that
it's available. Also removing a comment that's OOUI variable specific.
Bug: T334934
Change-Id: Id697baa9537013c9e240dbfaa9ead1eb15280133
The observation that the href for wrappers with mw-file-description
class will be the same as the resource still holds. However, on the
other end, if the href is null, setting it to resource doesn't work.
Timed media and when the "|link=|" media option is used, result in an
imgWrapper that's just a span and wouldn't have an href.
This patch fixes a dirtying of timed media in galleries that was
preventing selser from being used. Note, that <source>s in <audio> and
<video> tags are still dropped, so selser won't work yet.
Change-Id: Iefc520b8513e833665dae9d5c3a9dca2762264a6
Follow up to I02ea8421e468635ba6297bb5cda488a5a79c9a1d the depends on
I7a5c24f6ffc15ff0455adf5b025b695ee71501b6 in Parsoid.
Note that the mediaTag isn't currently being passed around for gallery
image nodes so, for example, a <video> becomes an <img> as is. But,
that's independent of this patch, and a follow up will fix it.
Noted in T348703#9278332
Bug: T348703
Bug: T214603
Change-Id: I5f7d3dfe0a41fac1568c97dccc41209c14e741d0
Replacing several values with MediaWiki skin variables featuring new
Codex design tokens, available since >= v1.41.0.
The values are 1:1 visual replacements in the default Codex
'WikimediaUI' theme, a continuation of the base vars, and the default
for Vector and MinervaNeue skins.
Also replacing
- other static color values with variables
- and outline value as the Codex default brings an accessibility
advancement for free
Bug: T334934
Change-Id: I512427803cffce1c16879015c45cf1e35fe17480
After the other changes in T346944, desktop Minerva can display
multiple edit tabs and section edit links without these hacks.
Bug: T346944
Change-Id: I3721f9387303386493664366988961242a26dba5
Video thumbnails have no alt attributes, and so we were causing dirty
diffs in any edit of a page that had a gallery containing a video.
Bug: T348703
Change-Id: I02ea8421e468635ba6297bb5cda488a5a79c9a1d
Some wikis customize messages, e.g. 'skin-view-create-local', in ways
that are not compatible with the client-side message parser.
Bug: T306807
Change-Id: Ie2f2ba4bba3b5b6f4fd6dbed6773d87f096a8944
* Remove incorrect overrides in VisualEditorTabMessages. Since
I44bd632682d5cc52b2660ad72a492f95a04be36e, the interface should use
'skin-view-edit-local' and 'skin-view-create-local' respectively.
* Fix the fallback mechanism in DesktopArticleTarget.init.js
to handle these keys correctly.
Change-Id: I7dad7e3a6fb920c5caf175e0e7500fd0c4b4d0ae
This JS code duplicates the PHP implementation in VisualEditorHooks
in order to allow changes to the configuration of edit tabs
(e.g. wgVisualEditorUseSingleEditTab and wgVisualEditorTabPosition)
to take effect for logged-out users immediately, without waiting
for the HTML caches to clear.
It was worthwhile 10 years ago when VisualEditor was being rolled out
to new wikis or reconfigured daily, but it is not today when we hardly
ever change these settings.
It proved difficult to maintain as the skins change, it has several
known bugs (T292125, T306807, T346944), and probably several more
unknown ones, given that it hasn't been tested in about 10 years.
Let's remove it and save ourselves the headache. (Also also reduce the
amount of code we ship on all page views by almost a kilobyte.)
Bug: T292125
Bug: T306807
Bug: T346944
Change-Id: Ib82f5402872a2429445463a1e1ef92806d3326f9
Allow Core to handle the toggling for Wikitext when the inline switch is
present to avoid duplicated functionality.
Bug: T345836
Bug: T346213
Bug: T346299
Depends-On: Ib88836f13cdb5cd2344e3ba12f6c942baa0fc1f1
Change-Id: I3bb9fcabe17a20c9934274766e3335f63d51aac4
VisualEditorFeatureUse as feature: notices, action: show.
This doesn't distinguish between the automatic on-load show and manually
showing them from the toolbar.
Bug: T344465
Change-Id: I5a0d7e87592c286afe51e02ae8436f7d2ce71021
I apparently forgot to pass the parameter to fireHookOnPageReload()
that I introduced exactly for this purpose. As a result, the basic
post-edit popup appeared, but the temp user popup did not.
Also rearrange code so that fireHookOnPageReload() is still called if
we need to redirect to complete creation of the temp user.
Bug: T344879
Change-Id: I36c64f27d2b8866ca88642621a135e7e25a91ce1
Abortable promises are definitely among my least favorite things.
It takes all of this bookkeeping to make .abort() work consistently
(so that it always aborts a request if one is in flight, and always
causes the final promise to be rejected even if we didn't start a
request yet or it has already finished). But, if you squint and ignore
every line with the word "abort", it's like a normal promise chain.
Depends-On: Iec8a15dadd595bed0f7e54f907fbb8e192b45cf3
Bug: T331397
Change-Id: I67309c79e6d211d69630fe89cbf5402f8fbd350c
A new hook `ve.preSaveProcess` is triggered to give other code the
chance to add steps to the process. The save dialog won't show until
the process completes. A step can be failed to return to normal
editing.
Change-Id: Id0740ff58ba9d9519c81174100ef1b8f8740870b
This method was only called, and the message was only shown, when
retrying after the first 'badtoken' error and refreshing the token
fails again.
If this happens, it usually indicates some terrible problem with
the wiki, and it is not something that can be fixed by logging in
again (or anything else the user can do).
Let the default API error message appear ("Invalid CSRF token.").
While not very helpful to the user, it should be more helpful to
the site administrator trying to unbreak their wiki.
Remove the "visualeditor-savedialog-identify-trylogin" message.
Keep "visualeditor-savedialog-error-badtoken", which is re-used
in another error message. I'll fix that separately.
Change-Id: Ib680218bce5ae38aa52d7d941218a6410ab7e09e
This has not been used for many, many years, since we started using
mw.Api#postWithToken, which automatically retries on 'badtoken' errors.
Most of our code for it was removed (e.g. save() is never called
with three parameters), but some comments and parameters remained.
Change-Id: Ibca2a222f808e6e2796ed6a61e9587a646afcf31
Occasionally we end up logging error codes like
"abusefilter-disallowed,abusefilter-disallowed,abusefilter-warning"
when someone hits a bunch of different filtes.
Change-Id: I967d374d13473ca684412b380d732653a3ceaff3
TODO comments suggested using the VE helper util, but
that is no longer necessary since all our browsers
support passive events.
Change-Id: Idb7e702d58931208d555a3f994cd0b73abec2e20
