Open Bug 1416721 Opened 7 years ago Updated 2 years ago

[twitch] The buttons glitch as long as you hover the cursor over them

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- affected

People

(Reporter: obotisan, Unassigned)

Details

(Whiteboard: [gfx-noted]) 

[Affected versions]:
- latest Nightly
- Firefox 57.0 - build 4
-Firefox 56.0

[Affected platforms]:
- Windows 10 x64
- Ubuntu 14.04 x64
- Mac OS X 10.11

[Steps to reproduce]:
1. Access a video that is not live on twitch.com (e.g. https://go.twitch.tv/videos/188200144)
2. Scroll down to the list for popular videos, recent videos etc.
3. Hover over the corner of the navigating arrows. 

[Expected result]:
- The button pops up a bit and then remains in place.

[Actual result]:
- The button glitches as long as you hover the mouse over it.

[Regression range]:
- I will find a regression range as soon as possible.

[Additional notes]:
- You can see how I recreated the bug in the attachment.
Oana, could you get a regression range for this problem?
status-firefox56: affected → wontfix
status-firefox57: affected → wontfix
Priority: -- → P3
I thought I could find a regression, but I can't. I can't even confirm if it's one, because on older version (e.g Nightly from 2015-01-01)the video is not loading. And in order to reproduce the bug, the video needs to play. 
But I can conform that this bug is reproducing even on Nightly from 2016-01-01.
Thanks Oana, that helps! On the hunting regressions side - is it possible you're testing on 64-bit builds?  Because they weren't that good that far in the past, and I know when I'm hunting for an old regression, I usually have to ask mozregression to use a 32-bit build.
Yes, I used only 64-bit builds. I will try to find the regression with 32-bit builds. 
Thank you for the information. I didn't even think about that.
It was a good idea, but I still can't find if it's a regression. On the builds from 2014-08-01, even if they are 32-bit, I can't play the video.
But now I found out that the bug is still reproducing even on a version of Nightly from 2015-01-01. More information, unfortunately, I couldn't find. I hope this helps.
OK, I can reproduce this.  Hovering moves the arrow, but then it wants to move back, and keeps bouncing back and forth.  I'm only about 40% convinced that this regression range is correct, but this is what I got: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=35b211eaad1fa828064514c547057e4400e24459&tochange=c39a71cf41460924d2988d2d63be2f5d267db82a

Fighting for focus?
Flags: needinfo?(bugmail)
Whiteboard: [gfx-noted]
This looks like a pathological case where hovering over the item triggers a transform animation, which moves the item so that you're no longer hovered over it. This then triggers the reverse transform animation, which moves it back under the cursor and so on and so forth. It just cycles infinitely between the two states. We shouldn't be getting into this infinite loop, but I'm not sure what triggers the :focus activation - I would have assumed it triggers from a mousemove event, in which case this implies that we're dispatching mousemove events even though the mouse isn't actually moving. That might be a widget or DOM issue. If it triggers from something other than :focus, the root cause might be somewhere else.

:heycam, do you know what triggers :focus style blocks to activate?
Flags: needinfo?(bugmail) → needinfo?(cam)
I know that we dispatch synthetic mouse move events when something on the page scrolls, which can then re-evaluate which element is hovered.  I don't know if that's the case here.

:hover matches when the element has the NS_EVENT_STATE_HOVER state bit, and that will be set and cleared in EventStateManager::SetContentState.  That's the place I'd start to look at what's causing the hover state change.
Flags: needinfo?(cam)
It seems like we are in fact dispatching synthetic mouse move events here, but not because of scrolling. It seems like we're doing reflows and that's triggering it, from [1]. I also noticed that this only happens on some videos. The main video linked in comment 0 triggers it, but sometimes that video is preceded by an ad, and the ad doesn't trigger it. I'm not really sure why the reflow is being triggered, but it might have to do with the copyright notice that displays over the main video regarding the soundtrack.

[1] https://searchfox.org/mozilla-central/rev/c9214daa09e3eb8246b1448e469df1652a140825/layout/base/PresShell.cpp#8860
Component: Graphics → Layout
Hmm, this is reproducible without Stylo enabled... For a second I wondered if this was bug 1376082...
This happens also on Chromium for me, fwiw...
I was seeing it in Chrome as long as the mouse was in motion. In Firefox it happens even if the mouse is not moving.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.