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
Notable:
* Arrays shouldn't be initialized like this. Instances will actually
share the same array object. Luckily this was dead code anyway
because it's re-done in the constructor.
* $timeOffset is already guaranteed to be an int.
Change-Id: Ib0a2b0f39ee368fcef4756281099d519d470eb44
This utility method doesn't really belong here. This does at least
reduce the surface area. Now it's only a single method instead of
two.
Change-Id: I21fbb4e4922f2cc3bc3e23c457b5ceeb216f3ab4
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
This is a manual revert of I06b8af8. Turns out the list of revisions
(and with that the maximum size calculated from the list of revisions)
changes during the lifetime of the view. It must be recalculated.
Maybe not as often. But this is an optimization for a later patch.
Change-Id: Id1dce5566a9041396bcf72df7e4936be0e53188a
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
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
