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
https://arewecompressedyet.com/

My specs:
Current Nightly
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

Actual results:

https://youtu.be/tkVQDCDNvhs

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.

Expected results:

The cursor should always hightlight the correct elements while hovering over the page, but in this case the position on screen is wrong.

PS:
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.

Hello :botond
I found a regression that seems to have been caused by your regression-fix.

I used mozregression and found your commit that introduced it:
https://bugzilla.mozilla.org/show_bug.cgi?id=1549625

It would be nice if you could take a look :)

Regards

Thanks for the report and regression window.

I haven't been able to reproduce this locally, but I also don't think it's worth trying to come up with more band-aid fixes for regressions caused by bug 1549625. We should instead fix the underlying problem properly (tracked in bug 1543485), and then back out the hacky fix in bug 1549625.

Could you check if the issue still occurs with latest nightly? I'm hoping that the fix in bug 1568826 fixed this as well.

I'll have to test again in 2 weeks.
I don't have access to the machine and can't seem to reproduce this bug on older Firefox versions over Teamviewer.

Happy to take a patch for 70, but since this is already triaged and set to P3 priority I'm setting it as fix-optional.
That will remove the bug from weekly regression triage.

(I'm pretty sure this is fixed by bug 1568826, which is in 69 and 70. Just waiting for the reporter to confirm.)

I'm going to assume this was fixed by bug 1568826. If it's still occurring, please feel free to reopen.