1221659 - Changing HTML5 video to full screen makes the entire screen black for 1.5 seconds before it reveals. As though the OS crashed

Status: REOPENED

(Core :: Graphics, defect, P3)

Description

[donrhummy]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151029151421

Steps to reproduce:

Watching an HTML5 video on YouTube, clicked the full screen button


Actual results:

The screen went completely black and then after about 1.5 seconds filtered to the full screen image.


Expected results:

It should have instantly showed the fulls screen video as it did in previous FF versions. The screen going black is very jarring and made me think that Firefox crashed the entire OS (especially since it went black immediately but took a while to filter back in the video). This needs to be fixed quickly.

Comment 1

[NoN@me]

I also experience this really annoying bug, which appears to have been introduced in FF42.0. At first a feared I had gotten a "black screen of death", and I had a terrible flashback to decades ago... But then I remembered I run a 64bit Linux, my hardware should be just fine.

A quick search on the web gives the following suggestion:
go into
about:config
(click yes)

Change the following settings
full-screen-api.transition-duration.enter from 200 200 to 0 0
full-screen-api.transition-duration.leave from 200 200 to 0 0

And yes, these are actually repeating... Why they are repeating I don't fully understand but perhaps someone else can explain.

After that the "black-screen-of-lag" should be gone (or at least it was for me).

Good luck and hopefully this bug can be resolved soon.

Comment 3

[Xidorn Quan [:xidorn] UTC+10]

I feel confused. How long would it take if you disable the transition via the approach mentioned in comment 1?

In theory, the transition takes 200ms+X+200ms, where X is the time the browser needs to enter fullscreen. X should always be there whether you enable the transition or not, so if you experience a 1.5s delay, it seems the browser takes 1s+ to enter fullscreen when there is no transition. Is that what you see?

If disabling transition makes things a lot faster, then we need to investigate why the transition is slow. If the browser change does take that long time, we need to investigate how can we improve the general performance for entering fullscreen. Could you provide some information to help diagnosing this issue?

Also it would be helpful if you can tell what window manager or desktop environment are you using.

Comment 4

[donrhummy]

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #3)
> I feel confused. How long would it take if you disable the transition via
> the approach mentioned in comment 1?
> 
> In theory, the transition takes 200ms+X+200ms, where X is the time the
> browser needs to enter fullscreen. X should always be there whether you
> enable the transition or not, so if you experience a 1.5s delay, it seems
> the browser takes 1s+ to enter fullscreen when there is no transition. Is
> that what you see?
> 
> If disabling transition makes things a lot faster, then we need to
> investigate why the transition is slow. If the browser change does take that
> long time, we need to investigate how can we improve the general performance
> for entering fullscreen. Could you provide some information to help
> diagnosing this issue?
> 
> Also it would be helpful if you can tell what window manager or desktop
> environment are you using.

The transition from pressing the fullscreen button to the black screen to then showing the full screen video is *more* than 1 second of time. It's usually 2-3 seconds. That's unnaceptable.

Comment 5

[donrhummy]

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #3)
> I feel confused. How long would it take if you disable the transition via
> the approach mentioned in comment 1?
> 
> In theory, the transition takes 200ms+X+200ms, where X is the time the
> browser needs to enter fullscreen. X should always be there whether you
> enable the transition or not, so if you experience a 1.5s delay, it seems
> the browser takes 1s+ to enter fullscreen when there is no transition. Is
> that what you see?
> 
> If disabling transition makes things a lot faster, then we need to
> investigate why the transition is slow. If the browser change does take that
> long time, we need to investigate how can we improve the general performance
> for entering fullscreen. Could you provide some information to help
> diagnosing this issue?
> 
> Also it would be helpful if you can tell what window manager or desktop
> environment are you using.

BEFORE SETTING THAT CONFIG PREF
--------------------------------
Going to Full Screen: 2-3 seconds of black screen
Leaving Full Screen: 2-3 seconds of black screen

AFTER SETTING THAT CONFIG PREF
---------------------------------
Going to fulls screen: 1/2 second pause with NO black screen, then instant pop in of fullscreen video
Leaving full screen: 2-3 of black screen

It's a bit odd that:

1. Leaving fullscreen is different than going to full screen after changing that preference AND that it still delays

2. There's still a delay going in to full screen but it's only about 1/2 a second AND there's NO black screen at all, it's just a delay of the entire screen freezing for 500 ms

3. Changing the preference from 200 ms to 0, makes MORE than a 200 ms difference. It makes about a 2 second difference!

Comment 6

[Xidorn Quan [:xidorn] UTC+10]

Hmmm, it is possible. I guess I should improve the transition impl for Linux, which is the only one that we handle the animation ourselves.

Comment 7

[Xidorn Quan [:xidorn] UTC+10]

Attachment: MozReview Request: Bug 1221659 - Make fullscreen transition on Linux take the designed time.

Review commit: https://reviewboard.mozilla.org/r/29211/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/29211/

Comment 8

[Xidorn Quan [:xidorn] UTC+10]

This should shorten the transition time on Linux to the designed 200ms + 200ms. But the transition still doesn't look as smooth as on Windows and Mac. Not sure how to improve that.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 8702886 [details]
MozReview Request: Bug 1221659 - Make fullscreen transition on Linux take the designed time.

https://reviewboard.mozilla.org/r/29211/#review26037

Comment 10

[Xidorn Quan [:xidorn] UTC+10]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2f4991bbb9fb2fc97b1dadf9b8fb9b465f12b87b
Bug 1221659 - Make fullscreen transition on Linux take the designed time. r=roc

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Backed out for making test_fullscreen-api-race.html and test_fullscreen-api.html nearly perma-timeout on Linux32.
https://treeherder.mozilla.org/logviewer.html#?job_id=19153084&repo=mozilla-inbound

https://hg.mozilla.org/integration/mozilla-inbound/rev/9108e17a2abc

Comment 12

[Xidorn Quan [:xidorn] UTC+10]

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #8)
> This should shorten the transition time on Linux to the designed 200ms +
> 200ms. But the transition still doesn't look as smooth as on Windows and
> Mac. Not sure how to improve that.

It seems changing the opacity in 30fps rate is smoother than in 10ms interval. The latter probably makes the system compositer too busy to handle.

Comment 13

[Xidorn Quan [:xidorn] UTC+10]

https://hg.mozilla.org/integration/mozilla-inbound/rev/34aff36bb1ac9435b5f61856caacc9c731a851b7
Bug 1221659 - Make fullscreen transition on Linux take the designed time. r=roc

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/34aff36bb1ac

Comment 15

[Xidorn Quan [:xidorn] UTC+10]

Comment on attachment 8702886 [details]
MozReview Request: Bug 1221659 - Make fullscreen transition on Linux take the designed time.

Approval Request Comment
[Feature/regressing bug #]: bug 1160014
[User impact if declined]: may experience longer than designed transition time
[Describe test coverage new/current, TreeHerder]: n/a
[Risks and why]: low risk, just changes the timing method of fullscreen transition, and only affects Linux
[String/UUID change made/needed]: n/a

Comment 16

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Xidorn, what does test coverage not applicable mean here? Did you manually verify that with the fix the black screen and 1.5 second delay is gone? If yes, could you please mention "manually tested" under test coverage in the future?

Comment 17

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

[e-mail], could you please verify this issue is fixed as expected on a latest Nightly build (1/5/2016)? Thanks!

Comment 18

[donrhummy]

(In reply to Ritu Kothari (:ritu) from comment #17)
> [e-mail], could you please verify this issue is fixed as expected
> on a latest Nightly build (1/5/2016)? Thanks!

It does not. I downloaded nightly, extracted the tar.bz2 file, went into that directory and opened a terminal, typed "./firefox -p", crreated a new profile and started firefox nightly with it. 

Went to YouTube, watched a video and made fullscreen and it went completely black for a few seconds, then showed the video.

What I don't understand is that a few old versions ago (42? 41?) this did not happen.

Comment 19

[Xidorn Quan [:xidorn] UTC+10]

I manually tested it fixed for static fullscreen transition which is improved. But it seems transition during video playing could still be an issue...

With the similiar hardware, the transition does look much better on Windows and Mac than Linux, probably because a more busy main thread on Linux during video playing (and the transition lives in main thread as well because GTK is not thread-safe).

We probably should just disable the fullscreen transition completely on Linux...

Comment 20

[Xidorn Quan [:xidorn] UTC+10]

Attachment: patch to disable the transition on GTK by default

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 8704395 [details] [diff] [review]
patch to disable the transition on GTK by default

Review of attachment 8704395 [details] [diff] [review]:
-----------------------------------------------------------------

Don't we need some kind of transition for security reasons?

Comment 22

[Xidorn Quan [:xidorn] UTC+10]

Fullscreen transition is a plus for security, but probably not completely necessary. And annoying transition actively encourages users to disable it manually.

Note that, we have disabled the transition for Windows XP as well as Windows 7 classic because on those platforms it is simply impossible to implement a decent transition due to system limitation (see bug 1184201). It is also disabled on Linux when no composition support presents from the beginning for the same reason.

So the same reason applies here again. Implementing a decent transition on Linux is hard, because GTK is not thread-safe which means transition cannot be smooth enough if the main thread is busy, and the main thread being busy unfortunately coincides with major use cases of fullscreen on Linux.

It is possible to do it better, e.g. via having a separate process which setup its own gtk and display the transition window, or alternatively, using X11 with OpenGL to create the transition window in a separate thread. But I guess it isn't worth.

Comment 23

[donrhummy]

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #20)
> Created attachment 8704395 [details] [diff] [review]
> patch to disable the transition on GTK by default

What will this mean? That it simply goes full screen instantly? What is the transition? Also, will removing the transition no longer show the popup that says "Now fullscreen. Press Esc to exit"? If it still shows that, then I see zero reason to keep the transition, even for security. That popup alerts the user that fullscreen has occurred.

Comment 24

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

I have also observed this bug on my win8 laptop on 44.0b7 and 45.0a2 (latest build). I would consider this bug blocking for FF44 release. The sooner we can get a safe and stable fix uplifted to Beta, Aurora, the better!

Comment 25

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Johnny, Jet, Xidorn: I consider this bug as a release blocker on Fx44. The 1-2 second delay upon switching youtube to fullscreen videos is an extremely poor experience. :( Could we get a safe fix (hopefully verified as well) uplifted to Beta/Aurora soon? Please let me know if I can provide any help in repro, verification of this scenario.

Comment 26

[Xidorn Quan [:xidorn] UTC+10]

I don't expect this happens on Windows. As I mentioned in comment 6, this happens on Linux because the transition runs in the main thread on Linux, and it seems we already have a relatively busy main thread on Linux when playing youtube video.

On the contrary, on Windows the transition lives in a separate thread and the animation is done by the system API, so the transition should be smooth and only take the designed ~0.5s in total for the transition. If this issue happens on Windows, we should have a separate bug filed with STR blocks bug 1187769. Could you do that?

The patch landed in comment 14 should improve the transition on Linux especially when *not playing video*, and it should be safe to uplift. But I haven't yet seen any solution of this issue with video playing other than disabling the transition, due to the reason mentioned above.

Comment 27

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Xidorn, Anthony: Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1187769#c4. The fact remains that this is noticeably bad on windows and really should be investigated as a high priority given Fx44 beta schedule.

Comment 28

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Xidorn helped me understand that this can be changed with pref values and he asked me to experiment with several values for that pref. Summarizing here what I told him:

1. Pref value 0 0, the video seamlessly transitions to full screen, continues playing and then the "exit fullscreen" pop up floats down.

2. Pref value non-zero (20, 20 or 50, 50 or 200, 200), there is a 1-2 second black window after which video resumes and pop up floats down. They both happens so close apart that it is hard to tell which is happening first.

Also, my 44.0b7 is non-e10s. Hope that helps!

Comment 29

[donrhummy]

(In reply to Ritu Kothari (:ritu) from comment #28)
> Xidorn helped me understand that this can be changed with pref values and he
> asked me to experiment with several values for that pref. 

This does not fix the issue on linux

Comment 30

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

I've talked to Xidorn about this and he confirms that it is his highest priority. He's going to add some NSPR logging to help diagnose the problem. I have personally used fullscreen more than 1000 times on a number of machines and not seen any issues. My guess is that it is racy and only affects some machines. Given that this will require some back and forth it may take a few days to get to the bottom of the problem. Hopefully adding debug information doesn't change the outcome.

Comment 31

[Jet Villegas (inactive)]

(In reply to donrhummy from comment #29)
> (In reply to Ritu Kothari (:ritu) from comment #28)
> > Xidorn helped me understand that this can be changed with pref values and he
> > asked me to experiment with several values for that pref. 
> 
> This does not fix the issue on linux

Bug 1240978 is now fixed. How does it look on your Linux machine?

Comment 32

[donrhummy]

(In reply to Jet Villegas (:jet) from comment #31)
> (In reply to donrhummy from comment #29)
> > (In reply to Ritu Kothari (:ritu) from comment #28)
> > > Xidorn helped me understand that this can be changed with pref values and he
> > > asked me to experiment with several values for that pref. 
> > 
> > This does not fix the issue on linux
> 
> Bug 1240978 is now fixed. How does it look on your Linux machine?

What version is this fix in? Do I need nightly?

Comment 33

[Jet Villegas (inactive)]

Nightly(47) or Aurora(46) should have the fix
https://bugzilla.mozilla.org/show_bug.cgi?id=1240978#c6

Comment 34

[donrhummy]

(In reply to Jet Villegas (:jet) from comment #33)
> Nightly(47) or Aurora(46) should have the fix
> https://bugzilla.mozilla.org/show_bug.cgi?id=1240978#c6

I used Nightly 47. It's better but still goes black for a second or two, then shows the video. And on esc, it also goes black for a second.

This is still not correct as making the entire screen black for a few seconds feel like it crashed the computer. It IS faster than FF 44, but the old FF didn't go black at all. - it would show the video fullscreen.

Comment 35

[Adam Porter]

I just upgraded Firefox and noticed this behavior on YouTube.  It's awful.  When I click the fullscreen button, the screen fades to black and stays black for about 5 seconds while the video continues playing in the background.  When I click to exit fullscreen mode, the screen goes black for another 5 seconds while the video continues playing.

I set the full-screen-api.transition-duration.enter/exit values to "0 0", and it removes the black screen, but there's still a 5 second transition period where the window is not yet made fullscreen, but the video fills the visible portion of the window.

On top of that, when I was changing that preference, I accidentally set it to "0" instead of "0 0", and it caused Firefox to keep hold of the mouse cursor focus even after exiting fullscreen mode.  The cursor moved freely, but clicking ANYTHING on the screen did NOTHING.  I could still use the keyboard, so I had to open a console and kill the Firefox process to get it to release the cursor back to X.

I use KDE with KWin OpenGL compositing on an AMD video card and the open-source radeon driver in Ubuntu Trusty.

This feature is quite badly broken and should not have been released yet.

$ apt-cache policy firefox
firefox:
  Installed: 44.0+build3-0ubuntu0.14.04.1
  Candidate: 44.0+build3-0ubuntu0.14.04.1
  Version table:
 *** 44.0+build3-0ubuntu0.14.04.1 0
        500 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages

Comment 36

[u279076]

(In reply to donrhummy from comment #34)
> I used Nightly 47. It's better but still goes black for a second or two,
> then shows the video. And on esc, it also goes black for a second.
> 
> This is still not correct as making the entire screen black for a few
> seconds feel like it crashed the computer. It IS faster than FF 44, but the
> old FF didn't go black at all. - it would show the video fullscreen.

Jet, how would you like to handle this? It seems like this issue isn't completely resolved for some users.

Comment 37

[u279076]

Still waiting for word from Jet on this bug report.

Comment 38

[Dave Miller [:justdave]]

Not sure if anyone's mentioned OS X yet (there's a lot to read here) but I can confirm this happens on OS X, too.  Hadn't really thought much about it until I was using Safari for something the other day, and in Safari, going to full screen continues playing while it animates, so you don't lose any video. On Firefox, the whole screen goes black immediately when you click the full screen button, there is no animation, and you have no video for a few seconds.  I sort of wonder if it's *supposed* to be animating during those few seconds of black, and maybe it's the animation that's broken.

Comment 39

[Dave Miller [:justdave]]

I'm using 48.0a2 (2016-06-04) on Mac, it's been this way for a while though.

Comment 40

[Dave Miller [:justdave]]

Oh, and I noticed something in one of the earlier comments about threading...  I do have e10s disabled because of incompatible addons, I suspect maybe that's related...

Comment 41

[Dave Miller [:justdave]]

OK, managed to force-enabled e10s, and that didn't help, I still have the total black screen with a delay before the video comes back when going full-screen.

Comment 42

[u279076]

(In reply to Dave Miller [:justdave] ([e-mail]) from comment #41)
> OK, managed to force-enabled e10s, and that didn't help, I still have the
> total black screen with a delay before the video comes back when going
> full-screen.

Hi Dave, can you provide a copy of about:support from the affect computer?

Comment 43

[Dave Miller [:justdave]]

Attachment: about:support

Comment 44

[Dave Miller [:justdave]]

That was taken while in Safe Mode, tried youtube that way to see if extensions were affecting it...  the delay was shorter, but it was still there.

Comment 45

[u279076]

(In reply to Dave Miller [:justdave] ([e-mail]) from comment #44)
> That was taken while in Safe Mode, tried youtube that way to see if
> extensions were affecting it...  the delay was shorter, but it was still
> there.

Thanks Dave. I wonder if you might try on a new vanilla profile just to make sure there's nothing in your profile affecting this (sometimes Safe Mode is not enough). 

If it still happens, what if you try changing gfx.canvas.azure.backends to cg?

Comment 46

[Xidorn Quan [:xidorn] UTC+10]

(In reply to Anthony Hughes (:ashughes) [GFX][QA][Mentor] from comment #45)
> (In reply to Dave Miller [:justdave] ([e-mail]) from comment
> #44)
> > That was taken while in Safe Mode, tried youtube that way to see if
> > extensions were affecting it...  the delay was shorter, but it was still
> > there.
> 
> Thanks Dave. I wonder if you might try on a new vanilla profile just to make
> sure there's nothing in your profile affecting this (sometimes Safe Mode is
> not enough). 
> 
> If it still happens, what if you try changing gfx.canvas.azure.backends to
> cg?

I wouldn't think that helps much. If the black screen takes several seconds, that probably means it takes too long time to switch to fullscreen...

Comment 47

[u279076]

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #46)
> I wouldn't think that helps much. If the black screen takes several seconds,
> that probably means it takes too long time to switch to fullscreen...

Please just check, thank you.