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
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
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
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
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
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
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
… and replace them with more trivial `function …() {}`. I
believe this does not make any difference. But I feel this
makes the code a little more straightforward.
The motivation for this patch is because a few other patches
change some of these function declarations, leaving a (in my
opinion) confusing mixture of styles behind.
Change-Id: Ib8928c4176a963afcf1fee1c785dd7bdc86c9706
In my PHPStorm IDE, this makes it possible to follow all methods and
properties in these classes, even these that are later defined.
Otherwise only the empty stub of each class is found.
This might be different in other IDEs.
Basically: PHPStorm does not understand the meaning of the $.extend()
syntax from jQuery without these hints.
Change-Id: I4aa76db183122f6669dc72561441f46f0056d793
This only solves part of the issue. Highlighting is applied for more
elements since they are retrieved from the DOM. The problem still exists
since highlighting depends on the RevisionList chunk on which is it applied.
To fix the issue completely highlighing should be managed somehow globally
on the global list.
Bug: T207781
Change-Id: Idda930f3d0dd64e767c68dade2ca8759bc636898
The next iterration on avoiding code duplication. I
still stuggle a bit merging these methods in a sane
way.
Change-Id: I8d95acc06da7f83a6133e55becabdf03b26a97af
- make use of toggelCSS()
- use more general jQuery selectors ro reset the line and bubble highlight
- get rid of ~= when selecting revision ids
Change-Id: I123e263bb379107a561fe8a2ffed476da9032b88
This is mainly a copy of what's done for the tag lines to set the events.
In the next steps I'll try to avoid code duplication here be extracting
common code.
Change-Id: I29df109de30c538cc206d445abff8464baf45378
The patch adds a first package of node selenium tests including
test for the user and tag filters.
The classes for user- and tag-rows were re-added to have better
access via selectors.
Change-Id: I8c53d9c923820e177d83ee900cee08e93cd3f65b
This moves the retrieval of the revisions into the method setting the
highlighting. The check for undefined did not to much since the rev
var would still remain undefined.
Change-Id: I1acf540f135af4c16fb80d633b3690473ada7833
* Uses the existing implementation of highlighting revisions from the same user
* Shows bubble next to tags in Tooltip
* When you hover on a bubble, tag row is circled, and revisions with a specific tag gets highlighted. When hovering ends, highlighting ends. But, if there is an active filter available, all previous states are restored accordingly.
* When you click on a bubble, in addition to highlighting revisions and tag row, any previous tag or user filter is removed.
Bug: T203581
Change-Id: I824a027a7f542eb7227545870553e58ec23542bb
