We added this more as an experiment because we couldn't reliably
figure out what makes later .offset() calls fail. After looking into
the actual jQuery source code I realized the only way .offset() can
return undefined is when .length is zero. Which means the two checks
are redundant and one can be removed.
In case an element is not attached to the document an object with
{ top: 0, left: 0 } is returned.
Bug: T342556
Change-Id: I6265fd27b3102a9cfe853a9c0e11063b76cf0b7b
Otherwise the `this` to call addColoredColumnBorders() inside of
that function is unkown when triggering the callback.
Can be verified working when collapsing the slider on master vs
this patch.
Regression introduced in Icffe9551d633470ccec1b63ea570e138db48dee8
Change-Id: I653db133688d7678d0cb3b80936c7e9a7ebebd1f
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
It turns out the view class doesn't really do anything with the
RevisionList object. All it does it manually iterating the array of
revisions. But it doesn't call anything from the RevisionList class.
With a single exception.
Warning: This doesn't mean the RevisionList class is pointless. It's
critical because this is where the relativeSize fields are calculated.
Bug: T224971
Change-Id: I06b8af815bb6f931355d68aa511070fb34b08156
Steps to reproduce:
* Make the browser window very narrow so that RevisionSlider can't
show the maximum number of gray bars.
* Go to a page with many revisions, open the RevisionSlider, and pin
it.
* Click the "Older edit" navigation link.
* Now make the browser window larger. Note how RevisionSlider will
have more space to show more gray bars.
* Use the browser's back button.
The pointer positions will jump to a random position.
The problematic code is in DiffPage.initOnPopState() where a "state"
object from the browser history is used to not only restore the
position of the blue and yellow pointers, but also the relative
starting position of the slider (the position you can manually change
with the large left/right arrow buttons). The way this relative
position is calculated depends on the number of revisions that fit
on a screen, which depends on the the available screen width. The
problem is that these numbers change after the state was recorded in
the browser history.
It might be that this patch still does not solve the issue in all
possible situations. But it already makes it behave much better.
Bug: T349208
Change-Id: If8e89457232061698c3821cae2d0aab3f7778b26
The offsetNotAvailable method is part of the class ever since it was
created in Iadf7793. It always only checked one of the two columns.
This confuses me, to be honest. The PointerLine class is meant to have
exactly two instances: One for the left (yellow) and one for the
right (blue) lines. There should be no reason the left reaches into
the right, and vice versa.
Bug: T342556
Change-Id: I31117b3a6bb73c397f7702cb3b162276de1a77ca
I'm sure this does the same as before. Note that we don't care how
many elements are found. Only if at least one element is found.
Whichever is found first, we can stop searching then.
This is especially relevant when the first jQuery search doesn't
find anything. It scans the entire DOM tree (upwards) then.
Combining the two means the search can stop earlier.
Change-Id: I0903c58f87fb133135a7b0de273460ff80fb45ff
The idea is to visually group things together that belong together.
This reduces duplication and hopefully makes the code easier to
read.
Change-Id: I609ee0eb5644de9c32984a3b2535652504e0e940
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
Calling .append() with a text message means jQuery will happily parse
it as HTML if it looks like HTML.
Found with the new x-xss debug feature.
Change-Id: I916f4dd8f530a8e88d34918a24fdfd28a86708f2
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
While working on renaming and consolidating some methods I found
it puzzeling, that the generic "highlight" word is already taken
by the filter mechanism. So I made these things more specific.
I checked the global wiki search if any user referes to these to
override CSS. It seems nobody does, so the change should be save.
Change-Id: I47c149978b0527c2d9e91709ef9d704526d56101
According to the compatiblity standards to give Grade A support
for modern browser versions not older than 3 years, we do not need
these workarounds anymore.
Change-Id: Ib1c42594b2c4077cabb010b8830a04ab10938a17
Mousemove events seem to bubble up and can trigger unwanted hover
effects when the tooltip is appended to the pointer container.
This regression was introduced in the patch that supports tabbing
into the tooltips in I75ef7c32fb105526552eac387ff5a5bda8eefe1b
Bug: T341872
Change-Id: I975cc054a760f2da1d8ea37d10d9a5bf00bf3ae2
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
This is obsolete since I75ef7c3 where we had to replace the
`font-size: 0.8em` with a fixed 13px.
Bug: T341872
Change-Id: I81603536dd930c6faee38c63aabe848203c42715
This was removed in I75ef7c3. Turns out it's needed for the
highlightable elements in the popups (e.g. when highlighting all
edits made by the same user). The text row in the popup gets a thin
gray border. This border needs some padding on the left.
The solution is to make the CSS selector more specific so it can
win over the problematic selector in Vector.
Bug: T341872
Change-Id: Ia029b92b5e049c60279b55177a62e03919dc55d8
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
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
According to https://api.jquery.com/html/ a jQuery object is not
supported in .html() although is works.
The .empty() is needed to avoid multiple sliders on resize.
Change-Id: I0ce4748e95529dbe27f82d6fd0aa2433bfda4375
Mostly motivated by the missing @type tag.
Also make the syntax more compact. This is significantly easier to
read, I would like to argue.
Change-Id: If5cea5ff66ed345df16a2b417f0db4c56db347c9
This might not be the best possible solution, but it improves the
current, obviously broken situation a lot. At the moment one of the
dots is drawn outside of the slider, even if the revision it should
point at is part of the slider. Turns out the revisions shown on the
slider are loaded in multiple steps. The first step misses one of the
revisions when their order is swapped. When the missing revision is
added later it's already to late.
Bug: T168609
Change-Id: I10d15d04d981c87d35b2431080182fb5e3eb2b2b
Removed the HTML in the tutorial message and used linebreaks(\n\n) in i18n/en.json file,
replaced .html( mw.message( '…' ).…() ) with .text( mw.msg( '…' ) ) in modules/ext.RevisionSlider.HelpDialog.js
and added 'white-space: pre-wrap' in class '.mw-revslider-column-text' in file modules/ext.RevisionSlider.less
without affecting the front end of the page.
Bug: T267128
Change-Id: Iaf8b1819ca3139c18fb65cfca1c0b2120abb10f4
The new mw eslint config comes with node 12 and the change will be
quite big due to the lock file. I wanted to keep the diff of actual
code changes seperate.
- Applied all code style recommendations
- Removed one test that's not giving any value
- Changed regex .match to .test for performance and convinience
Change-Id: I578be8c6460c7a4d1220354c028a9bfd9bb86d13
It's never used in another context but together with the
….Slider module.
Motivated by the confusion about the two types of require()
introduced in Idf1cc79.
Bug: T233279
Change-Id: I922d7ab56fd3ce80bc901f1a5d7174df6fe6756d
It's never used in another context but together with the
….Slider module as well as the ….init module. The ….init
module continues to require the ….Slider module, so all
dependencies are still met.
Motivated by the confusion about the two types of require()
introduced in Idf1cc79.
Bug: T233279
Change-Id: I4b4ef69f3074d57f884763c092a515ce976daaef
It's never used in another context but together with the
….Slider module.
Motivated by the confusion about the two types of require()
introduced in Idf1cc79.
Bug: T233279
Change-Id: I7c98a41051e6d83ab3524cb14a709002feec2d78
It turns out the jQuery documentation is incomplete:
$( '<a>' ).offset() → { top: 0, left: 0 }
$( '<a>' ).parent().offset() → undefined
The difference is that the jQuery set in the second example is
empty.
Bug: T282067
Change-Id: I7c19162f1a39bd529e0a74a6cc0c1ac987f33657
