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
Really just a mistake.
Also make use of strict types while we are here. We can do this now
with our minimum PHP version.
Change-Id: Iab83a4c538b648f19a803442d1e839389f4d9cc4
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
