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
Turns out this code can only ever access a single underline: The one
it owns and can access via it's own this.$html property. One of the
two jQuery selectors always turned out empty, and calling .css() or
anything else on an empty jQuery collection just doesn't do anything.
This patch also contains a similar, but technically unrelated
cleanup in the init code.
Change-Id: Ic89b11971f51f5dcca67dcbd308f65310f48f0ec
Two almost identical pieces of code, both adding revisions to the
list.
There is a 3rd one that prepends revisions. I leave this untouched
for now.
Change-Id: I4798c8c2d6e0f9b70f7ea0dc20bb271514c03350
When the user uses the keyboard to interact with the slider, the
revisions can changed by moving the pointers with the arrorw keys.
In that case the pointers have keyboard focus. To allow tabbing
into the popup from that position, the tooltip needs to follow the
pointer in the DOM. That's what's done in this patch.
Bug: T341872
Change-Id: I75ef7c32fb105526552eac387ff5a5bda8eefe1b
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
The plain wikitext comment is apparently not used for anything,
anywhere. It was for some reason used for an "is empty" check. But
we can do the same with the `parsedcomment`. I checked and an empty
comment doesn't result in something non-empty like `<div></div>`, but
stays as an empty string.
Change-Id: Iedc5898b7b0f82231328ab3e0e46b1461ca845b1
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
I removed this aria-hidden, because the RevisionSlider as a whole
can be accessed with the focusable button that expands the UI.
Elements that are focusable should not be aria-hidden.
screenreaders in general will allow interaction with these or even
might show unpredictable behavior.
Screenreader and keyboard support for the feature is not good but
this aria-hidden is useless and wrong at the moment.
Bug: T339254
Change-Id: I8b8e3938cba701c821d4fd2ee3c2f90bf7610623
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
I'm not sure why it was done like this. It looks like we can skip
both the extra conditional as well as the extra function scope.
Change-Id: I9aebd17bece0b9a573fc1f9697e79b759741751e
This is certainly not an actual fix for anything. But it makes any
resize issue look much less broken and much more bearable. I think it
is helpful to have this extra safety in place even after we properly
fixed the issue.
Bug: T336729
Change-Id: I724ede9cda120f18c4b7ee3ebf7bb41c0541819e
This is best-practice, as far as I can see. It doesn't make a
difference in terms of what is stored in the database. false,
the number 0 and the string "0" will all be stored as "0" in the
database. More precisely: These values will not be stored because
they are all considered equal to the default value by
UserOptionsManager::isValueEqual().
It makes a difference in terms of what is send to the browser. The
keyword "false" is 5 bytes while "0" is only one.
Bug: T300371
Change-Id: Ia9eb03ebdc2155df1785fa5d40bceaab56268bf9
