This doesn't change anything but is just a code style question. I
find it less confusing than a numeric comparison, to be honest.
Change-Id: I6ef220e85e395fe4769103e20402e1e540946778
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
Most callers use it as if it's a `getElement` call anyway.
There is one .initialize method left in the HelpDialog class. That's
part of the upstream OOUI Window interfaces.
Change-Id: I5727c59ad0ad05d712d51d255906ddc44e898668
In RTL mode the slider is flipped and goes from right to left. The
revisions increase from right to left. The left cursor key needs to
be the one that increases the position.
Note there are three different "RTL scroll types" called "default",
"negative", and "reverse". This is only about CSS positions and
doesn't affect the cursor keys.
Change-Id: Ie747aa2572f2542b6c2c2176f817dd9a42b29f78
When we load new revsions in the background and extend the view,
we still want to keep track of the positioning. This is done with
the `data-pos` attribute. When shifting the numbers due to
re-loading the `data-pos` of each revision is updated to a new
value.
$.data() does not nessecarily load the value from the `data-`
attribute, but seems to have a different representation in parallel
In some situations the results of data() vs attr( 'data-' ) seem
to differ, leading to situations where the pointer moves to the
wrong postion when clicking.
Trusting the attribute call seems to be the most stable approach
here.
Change-Id: I3c877b5a5f21ca36b8857d29ec018b16ff588962
This is split from I4431882 to make that easier to review. This just
moves existing code around. It should not make any difference.
Change-Id: Ic1a63bac4c30656533c2323a5a133aa483a26975
This is split from I4431882 to make that much easier to review.
Additional changes:
* Remove plural "s" from setRevisionPreviewHighlight
* Add "All" to removeAllRevisionPreviewHighlights
* Merge two methods into a single enableRevisionPreviewHighlights
Change-Id: I7088b23a330a46fadfc4ae296cf1d61f0be435f8
This does the same as before, just in one single loop instead of so
many different steps.
The way the loop counts is odd. Why are the numbers returned by
getOldestVisibleRevisionIndex and getNewestVisibleRevisionIndex
off by one? I tried to make this more visible in the code without
touching it.
Change-Id: I5b9bd360bf48e138a7ae9406eab716d41fabd122
The extra "div.…" doesn't make the selectors more specific or
anything. The class name alone is unique. This makes the code
simpler, less brittle, and potentially even faster.
Change-Id: I38f61a793a3f5d441b9bf06f9159433cb7f002ad
This code is updating the position and length of the yellow/blue
horizontal lines in the middle of the slider, left/right to the
yellow/blue circles.
1. setSliderLineCSS is called two times. A lot of the code before
is identical. Move all code that is identical into setSliderLineCSS.
2. The two single-use methods are very short now. Nothing but a
single function call. Merge the two calls into a single method.
Notice that `-0.5 * this.revisionWidth` is the same as
`-this.revisionWidth / 2`. I was able to make one disappear by
slowly transforming the code. It still does the same as before.
Change-Id: I9f9593bf4655fc8fa681fa8190db44dc8d6fc232
Storing a new entry in the browser history is the normal, default
thing to do. The only exception is on initialization, when the slider
is initialized from the browser history.
I hope this makes the code a little easier to read.
Change-Id: I09a3e9b4417ec3d57e86dc947ac0748f30ef0dd5
This click handler is assigned to many different elements. Not all
of them can be used as a source for a data-pos="…" attribute. But a
lot can.
Again, this patch alone will not actually fix T352169. But it will
improve the situation a lot, according to my local tests. Many of
the clicks will start to work fine on RTL wikis because the
problematic pixel-based getRevisionPositionFromLeftOffset
calculations are not used any more.
Steps to reproduce: Go to a RTL page with a very long history, e.g.
https://he.wikipedia.org/wiki/Special:Diff/38031767?uselang=he
Click on one of the gray bars in the right half of the slider. This
will not work, i.e. the slider will not move to this position but
to a totally different one. This is the bug described in T352169.
I noticed that a browser zoom other than 100% can cause many more
problems that are unrelated to this patch. Please test with 100%.
Bug: T352169
Change-Id: Ife49557c891736bc94df6087658f76326791f61b
The method is only called from two places, and both do very similar
things before the call. This duplication can be merged.
One notable difference is that .scrollLeft() was possibly called
twice before. The first call was pointless anyway. The argument for
.scrollLeft() is absolute, not relative.
This code cleanup is motivated by T352169, but doesn't solve it.
Bug: T352169
Change-Id: I75e9ffc77ef6331f14e074921c78c28233e60840
This was almost the exact same code, with very few differences (e.g.
different CSS classes, and different icons).
Another change in the same file is the removal of an extra
`!== undefined` check. This is impossible. I can't tell why this was
there. Maybe an artifact from when this was developed?
This code cleanup is motivated by T352169, but doesn't solve it.
Bug: T352169
Change-Id: I3bb7ce00f9b754f9ba58310100b855c8ee3fca4a
Turns out we can run into this failure situation even if everything
goes according to plan. It is possible to click just one pixel outside
of the valid range, e.g. on the very right corner right next to the
last bar. This is supposed to not do anything anyway, and correctly
doesn't do anything from the user's perspective. But it shows up as a
failure in the JavaScript console.
Bug: T352169
Change-Id: I12c9cce90970be36667ba1b721afd38a13a063c9
When expanding the slider to newer or older revisions the handler
for revision clicks should only be added to the new revisions.
Change-Id: If590996d27dc75cbdfc931e9649418f875c3869d
This is a first step in restructuring and consolidating the
highlight and tooltip creation. I use revision focus to communicate
the state when a revision is highlighted and shows a tooltip.
There's still stuff to untangle but I want to keep the diffs small.
Change-Id: I0b169042837a2c3bb825c23368e7e8a485694eb5
See T349208 for an explanation. It looks like the SliderView.render
function was written with the assumption that it's only triggered
once on construction time. But since T139101 it's triggered again
for every window resize event. This adds the same event handlers
over and over again to existing elements that aren't affected by
the SliderView.render function.
This will probably become even worse with I49878fd (T336729).
Please test this carefully. I'm not 100% sure this is the best
possible fix.
Bug: T349208
Change-Id: Iba22924b660f2709c0680aa6fbeb0feba92cfa76
There's no need and probably just minimal gain to use these methods
with a revision as input. We could always just cleanup all tooltips
or wrapper highlighting before we set a new one. Makes the code
much simpler.
Change-Id: I34594843ccafa83372c796ff8cca68c4d6b58e06
Adds two handlers to make sure the popup is closed when the focus
moves away from either the pointers or contents of the a popup.
Bug: T341874
Change-Id: Ia68fc5ffbb63b4a534c84987879499e06cd60238
The pointer click and revision click handlers did almost the same
and the former was able to handle events from the latter. I merged
them and could then shortcut some code.
Change-Id: Id224b8d8da653110134cce0385da3a18cd073ecf
I'm not sure why it was done this way. Probably because it doesn't
make an actual difference from the user's perspective. My motivation
is: When we already called the code that auto-expands the
RevisionSlider UI then it doesn't make much sense to give the user
a keyypress handler that does the same a second time.
Possibly even related to T342556?
This patch also contains a few small, unrelated code cleanups.
Change-Id: I123e89d9d7dc3b1e33cf43831c679330d9dd1cdd
It took me a while to come up with a solution for this, but there
are several things that seem to trigger the showTooltip method a
bit to often.
Tooltips can be triggered either by the handlers that deal with
mouseenter and mouseleave events that also trigger revision high-
lighling. But tooltips can also be triggered when you use the
keyboard or the mouse while dragging sliders.
The mechanics on what's highlighted and what's triggering a popup
are a bit weiridly setup and there could probably be a major re-
factoring done to make things clear ( for example the show popup
method also highlights the revision but the highlight revision
mehtod does not ). I had a quick approach to fix that, but it's
not too easy.
Another issue is, that some events fire off a delayed popup close
mechanism. So the solution here reads like:
If you are triggered to show a popup, and that popup exists
already, stop the delayed popup close mechanism and bail out.
Bug: T341872
Change-Id: I2646a69cccd549af902d57fdf4ff6fb0e94cbe64
This code was designed for the left/right cursor keys. But it
currently triggers on all keys. This causes confusing behavior when
tabbing through the UI. This code also triggers on tab/shift+tab,
which can be visibly seen when the wrong popup opens. It also
triggers on enter, which feels like it's intentional, but is nore a
happy accident.
Especially note how the buildTabbingRulesOnKeyUp handler directly
below does the exact same: It only acts on left/right, but no other
key.
We intentionally keep the existing (even if bogus) behavior for the
enter key. To be replaced with something better in a later patch.
Bug: T341874
Change-Id: I75aac4ea3a66a69a44756159c8a98acdc6e74b01
Reintroduces IIFE closures in test files because variables were
declared in the global namespace, and "const" now causes hard errors.
Bug: T339323
Change-Id: I69e9d7a29591137f185f3e5ab02dea590ec4dff6
