Closed Bug 1563493 Opened 5 years ago Closed 5 years ago

Video player control images flicker on HBOGO when moving mouse on/off the controls

Categories

(Core :: Graphics: ImageLib, defect, P5)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1580820
Tracking Status
firefox-esr60 --- wontfix
firefox-esr68 --- fixed
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- fixed
firefox71 --- fixed

People

(Reporter: csasca, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

Affected versions

  • Firefox Nightly 69.0a1
  • Firefox 68.0
  • Firefox ESR 60.8.0

Affected platforms

  • Windows 10 (x64)
  • Ubuntu 18.04 (x64)
  • macOS 10.14

Steps to reproduce

  1. Start Firefox
  2. Access https://play.hbogo.com/login and login with valid credentials
  3. Select a movie and play it
  4. Click on fullscreen.

Expected result
The HBO player's UI is working as expected.

Actual result

  • The player has some controls disappear and reappear on interaction.

Regression range

  • I will see if there's a regression for this asap.

Additional notes

  • The issue can be seen in the following attachment.
  • On Windows 10, if already on fullscreen, the user can only exit with esc, as the UI controls are not interactionable at all and if the controls bar hides, the user cannot trigger it back again on mouse movements.
  • Windows 10 seems to be the most affected version, as Ubuntu and macOS doesn't have the fullscreen problem, but they still have the UI controls issues.
  • The controls appearing and disappearing is intermittent.
Has STR: --- → yes

The Windows 10 issue with full screen exiting is tracked in bug 1328269.

I don't have an HBO Go login, and also I get a geofence ("You are not in the U.S.") error. Can you use the devtools inspector to determine if there's a "controls" attribute on the HTML <video> element?

A regression window would also be very helpful.

Flags: needinfo?(catalin.sasca)

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression
Has Regression Range: --- → no

This issue looks like a dupe of bug 1562837 after all, that seams to have a fixed ready.

While searching for the regression range I could see the actual buttons disappearance way back to Fx 68.0a1 (2019-04-08), a little bit earlier that the regression mentioned in bug 1562837, but without arriving to a clear conclusion, since on my end this has an intermittent behavior. Also, here is a screencast with a variation of the hbo video controls problem.

With this mentioned, we will verified the issue, once the fix provided by Ehsan Akhgari will arrived in bug 1562837.

Flags: needinfo?(catalin.sasca)

Anca/Catalin, is this fixed now that bug 1562837 has landed?

Flags: needinfo?(catalin.sasca)
Flags: needinfo?(anca.soncutean)

The actually buttons disappearance is no longer reproducible with the fix introduced by bug 1562837, but I still can see the flicker of the control buttons on hover, with the latest Nightly 70.0a1 (2019-07-11): see screencast (bad). But when attempting to find a regression range using mozzregression, with the same build I couldn't reproduce the issue: see screencast (good). I will try tomorrow to investigate more around this behavior.

Flags: needinfo?(catalin.sasca)
Flags: needinfo?(anca.soncutean)

Hi, so from what I could gather, the regression range got me to this pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=39c8abcf9cb2f40b78289a5535fe550368302423&tochange=fdbb1ad695392bc5e5e00200013dee7c98a54967.

It seems that the issue is reproducible from Nightly 2018-10-02 onwards. I hope that regression leads to something, and if we could help with any further investigation, please let us know!

I'm confused between comment #5 and comment #6 what the state of this issue is and what (if anything) remains to be done. If someone could clarify, that'd be helpful in terms of prioritizing this...

Is the regression window from last year about the flickering of the controls, or the full screen button?

Does the problem go away if you set network.cookie.cookieBehavior in about:config to 0?

Flags: needinfo?(catalin.sasca)
Attached image Hbo GO flicker.gif

Hi Gijs, the state of this issue is about the controls in the HBO player flicker on hover (can be seen in the attachment). The regression I made was for the flickering of the controls.

The problem is still there if network.cookie.cookieBehavior is set to 0. This was reproduced on latest Nightly 70.0a1 (2019-07-21).

Flags: needinfo?(catalin.sasca)

:baku, looks like the flickering is a result of reloading images, which might make it plausible this was regressed by bug 1495738 (based on the earlier window posted of https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=39c8abcf9cb2f40b78289a5535fe550368302423&tochange=fdbb1ad695392bc5e5e00200013dee7c98a54967 ) - can you take a look?

Component: Video/Audio Controls → ImageLib
Flags: needinfo?(amarchesini)
Product: Toolkit → Core
Regressed by: 1495738
Summary: Video player controls are broken on HBOGO → Video player control images flicker on HBOGO when moving mouse on/off the controls
Priority: -- → P3

Do you think you could double check the regression range from comment 6? And double check that network.cookie.cookieBehavior set to 0 doesn't change anything?

It seems a little odd that the patch from bug 1495738 would be causing this. If bug 1495738 were causing this then I would think that before bug 1495738 the way that HBO go avoided the flickering was being very very lucky and having document pointers get re-used exactly in a way that helps, which seems impossible. So it seems reasonable to double check the regression range.

Flags: needinfo?(catalin.sasca)
Attached image cookie behavior.gif

Sure thing, I double checked with network.cookie.cookieBehavior set to 0 and the issue is still reproducing on latest Nightly (2019-07-29), I will attach a gif with that here.

I re-did the regression and I got different results this time, the issue seems to be somewhere between the 2018-10-01 and 2018-10-02 builds. Between them, it seems that there are many other builds, and I think that's why I got inconsistent regression ranges. I will attach here a picture with mozregression and the builds it got me.

This is the final pushlog which will hopefully be helpful: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4392b5198fb7773f6148d2caedff82da5f527bfe&tochange=0d4e73bc2cd705d7a021c75a0e8aeb174ab4db59.

Please let me know if I can be of any help.

Flags: needinfo?(catalin.sasca)
No longer regressed by: 1495738

Changing component, no idea if this is right but imagelib doesn't seem like the place.

Component: ImageLib → DOM: Core & HTML

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Priority: P3 → --

There was no DOM:Core&HTML bug in the pushlog in comment 11 ...
I couldn't find something obviously suspicious there, either ... ... not sure which is the right component for this issue.

The two below seemed more relevant though.
Bug 1492563 - Enable blocking access to storage from tracking resources by default on all desktop platforms on Nightly
Bug 1495738 - Image cache entry should compare the window ID together with the loadID because the loadID can be a reused pointer, r=aosmond

Priority: -- → P5

Perhaps I was too quick to say that bug 1495738 didn't cause this: bug 1580820 is a regression from bug 1495738 that is similar and it has a patch now, so let's check if this gets fixed by it when it lands.

Regressed by: 1495738
Component: DOM: Core & HTML → ImageLib

Can you retest in latest nightly? (that should have the fix for bug 1580820 now)

Flags: needinfo?(catalin.sasca)

Yes. It seems that the issue is fixed with the latest Nightly (2019-09-18) under Windows 10 (x64).

Flags: needinfo?(catalin.sasca)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE

Thanks!

Flags: needinfo?(amarchesini)
Has Regression Range: no → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: