User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
Steps to reproduce:
I surfed on AWCY and noticed something odd
Win 10 education edition 64bit
Intel i7 6700k
Nvidia GTX 980
This bug happens with hw acceleration enabled and disabled. (I tested both)
I attached the about:support json
Under certain circumstances the registered cursor position is about 160px above the actual cursor
At first I thought this was due to an iframe, but AWCY uses JS and only works in the same DOM.
So I don't know at all what causes this.
Once I start selecting text, then it snaps back after a few seconds (the second time in the video it takes noticeably longer)
Scrolling also updates the cursor position correctly.
If I don't scroll or mark text, then the registered cursor position stays this way. (nevermind I tested it again just now and it fixed itself after some more time)
I can reproduce this on a new profile, but it doesn't always show up.
I try to select one daala run, scroll down on the right page so you can see the list of videos/"analyzed links" section, select another run and very quickly deselect the other run to prevent AWCY from comparing the two (and to keep the scroll position of the righthandside div the same).
And then sometimes the cursor behaves this way.
The most interesting part about this is, that it only happens to part of the DOM.
Everything left of the scrollbar, where I can select daala runs (or other codecs for that matter) is not affected by the bug. The cursor position is detected accurately as expected. Only the divs/elements to the right of the scrollbar are affected.
So you have to select and deselect runs and then move the cursor to the right side to see whether you were able to make the bug appear.
The cursor should always hightlight the correct elements while hovering over the page, but in this case the position on screen is wrong.
Some ideas what maybe caused this:
The cursors position is detected wrong. (unlikely since it works in other parts of the dom)
The cursors position is detected correctly but I modified the page very quickly by clicking buttons and maybe this provoked a race condition that triggered something that causes the distance to the top of the page to be different from the one some part of the code actually expects.