The library was introduced in 37dc0b5ad to mock the History API. However
the extension package.json is solely used for linters such as eslint.
The JavaScript dependencies should be provided by a Resource Loader
module and mediawiki/core already provides Sinon.JS for the QUnit tests
(see tests/qunit/QUnitTestResources.php).
Remove sinon from this extension package.json and thus partially revert
37dc0b5ad. The sinon variable is still defined to please eslint.
Bug: T370573
Change-Id: I03d7fef161730d9f36b1367d931641430df4bfed
Updates the borders for the RevisionSlider box to use Codex design
tokens with dark mode support instead of hard-coded colors. The slider
itself still doesn't look ideal on dark mode to my eyes, but at least
with the slider in collapsed state it looks better now.
Bug: T370570
Change-Id: I6035781169e9a18f1c959032f605b8e72878aba5
This doesn't fully solve T370572 but already improves the situation
a bit, without causing any change in light mode. Notably: The 1px
separator between the individual bars was hard-coded white before.
I suggest to continue working on this in separate patches, not make
this patch more complicated.
Bug: T370572
Change-Id: I1a2159221bfc37f23e85e6aa7d6beed1f149163f
The border color was added 20016-08-12 via Id561485.
The border was removed 2016-09-15 via I1fdc0ec.
The color is meaningless since then.
Bug: T370572
Change-Id: Ic7a190bf3b56903f2afdd989eb1e78fa02ac01d9
I mostly refactored what's there. Instead of replacing parameters in specific links,
I'm going for the parent menues where these links live in and replace them completely.
Thereby I could also merge the edit and ve-edit selectors.
Also adding the footer that includes the link to the mobile view and seemed missing.
Bug: T211557
Change-Id: I263c82e80c675918683340d1bb01291213797f9f
Also use the selector
'.catlinks[data-mw="interface"]'
instead of
'#catlinks'
like in mediawiki.page.preview.js. This prevents selector injection by
the wiki content.
This change allows consuments of the hook 'wikipage.categories' to work
together with RevisionSlider.
Change-Id: I274e3d3b8ac94cc21c7b0878425c9a785a09b964
The selector '#mw-panel' from skin Vector and some other skins is not
stable to use and not available on other skins like Vector-2022.
The update of '#mw-panel' breaks CollapsibleVector: T211557.
Using $( '#t-permalink' ).parent() is also a dirty hack but it probably
works on all skins.
The .parent() also updates siblings like '#t-urlshortener' from
extension UrlShortener.
Also add $( '#ca-delete' ).parent() to update the other portlet links.
Bug: T211557
Change-Id: I084c93e8fe7c7663d9de8a39433a9e92a3827196
This generates the DOM elements directly instead of generating and
parsing HTML.
Also move the dependency on module 'mediawiki.jqueryMsg' from module
'ext.RevisionSlider.init' to module 'ext.RevisionSlider.Slider'.
Change-Id: I3a93b942e08ff7453e2b940c7f3e896f90679d0d
The `[data-mw="interface"]` in the selector prevents selector injection
by the wiki content.
The `.length` prevents unneccessary calls with emtpy list.
Change-Id: I434371539355e305d9faf569371ab5a686b2caff
from module 'ext.RevisionSlider.init'
to module 'ext.RevisionSlider.Settings'
where mw.Api is used.
Change-Id: Idcc0e3e670fa3eddb0cd121b1de42aabca6bd6ae
The MobileDiff page no longer exists, and was replaced with a redirect
that redirects to the desktop diff page, so this code can safely
be removed.
Bug: T360389
Change-Id: I8ebe2bc88a650caf29a5755013e980fe3b5aaeb0
This code was added in 2016 via Iadf7793. The two CSS classes
.mw-revslider-older-diff-column and .mw-revslider-newer-diff-column
became unused only one month later via I317a2fc. Since then all
this is apparently dead code. There are no "top borders" on these
columns any more. Lines still appear in the same position, but as
"border-bottom" on other elements.
It really looks like we just forgot to remove this.
Change-Id: I627628fa44da96ca1f1301d3a879919e4a021e5b
According to https://www.mediawiki.org/wiki/Compatibility we can:
* Ignore Internet Explorer as well as "Edge legacy" (before it
switched to Chromium) entirely.
* Ignore old Opera (Presto, before it switched to Chromium).
* Ignore Chrome and Chromium-based browsers that are more than
3 years old.
According to https://github.com/othree/jquery.rtl-scroll-type
* Firefox and Safari always followed the web standard.
* The "reverse" type was only ever relevant in IE.
* The "default" type was only relevant in old Chrome and
Chromium-based browsers, before the engine was changed to follow
the web standard.
According to https://chromestatus.com/feature/5759578031521792 this
happened in version 85, June 2020.
The only edge-case I can think of is that we want to support some
niche browser that – for some reason – still uses Chromium 84 or
older. But according to https://www.mediawiki.org/wiki/Compatibility
we are at 88+ already, everywhere.
It appears like we can safely remove two types, which means only
the web standard behavior (a.k.a. "negative") is left.
No pressure merging this. This patch can as well sit here for
another year. ;-)
Bug: T352169
Change-Id: Ifdedfd6d16abc87576df9807a55cd1b8a7d185db
This is closely related to Ied0b974 which fixed a similar, if not
the same rounding issue.
Note the following might be different depending on e.g. the
operating system. My Ubuntu+Chromium shows the following behavior:
* The RTL scroll type is correctly detected as "negative" with all
zoom factors below and up to 100%.
* When the zoom factor is 110%, 125%, or 150% the scrollLeft value
is not 0 but something like 0.909090876 or 0.200000002.
* It's 0 again at 175% and 200%.
* Bad at 250%. Good at 300%. Bad at 400%. And so on. No rhyme or
reason.
The current Firefox version also ends in the "negative" branch, but
doesn't have the same rounding errors. It's always a perfect 0 in
Firefox.
This makes it look like a bug in Chrome's engine. We don't know how
old it is, but based on the information in T352169 it might be a
relatively new bug that didn't exist when this code was originally
written in 2016 (see I7c903c2).
For reference, this is what's supposed to happen here: Browsers with
the scroll type "negative" (which are apparently all current Chrome
and Firefox versions) won't allow scrollLeft to be a positive number
on an RTL page. When you scroll to the left in such browsers the
numbers get negative. The detection code tries to set the number to
+1 anyway. We expect the browser to ignore this invalid call and
still report the previous 0.
This mostly works in Chrome as well. For example, setting scrollLeft
to +100 wont set it to +100 but to … some random number between >=0
and <1, depending on the current zoom factor? o_O?
I suspect we can remove this detection code entirely, or at least
change the default to "negative". But this needs more testing with
more browsers. Let's start with this tiny fix.
Bug: T352169
Change-Id: I22cbb8881578e96165097d4fcc812baadc22d7fa
