Open Bug 1222776 Opened 9 years ago Updated 2 years ago

Fade to fullscreen is probably too long

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect

Tracking

()

People

(Reporter: evilpie, Unassigned)

References

(Depends on 1 open bug)

Details

One of the recurring themes on /r/firefox the recent days have been people complaining about a black screen and trying to remove the fade-in and fade-out completely. Chrome for example doesn't do this at all, and compared to that our 200ms feel quite long (subjectively to me, it feels more like 1/2s or something). I think we should seriously consider making this even shorter or removing it.
Flags: needinfo?(jaws)
We actually have 200ms fade-out and 200ms fade-in, which is in total ~1/2s. Chrome does this, on OS X only, though. It is a question that, is the transition too long, or the black screen is too long? The transition is there because it helps mitigating potential phishing attack (especially given we've removed the permission requirement). It also helps hiding the broken intermediate state of the window when switch to fullscreen.
Personally I don't like the total black before the video, but I believe it's mostly about the fade.
I would prefer that we instead scale the element to the size of the display, maintaining aspect ratio. Fading to black and then back to the content just gets in the way, this is especially annoying if I'm watching a video and click the fullscreen button and miss a crucial part of a video.
Flags: needinfo?(jaws)
And again: https://www.reddit.com/r/firefox/comments/3slwh3/on_youtube_videos_my_screen_goes_black_for_05_to/ Seriously every other day ... Who can I ping to make some kind of decision? Is this more security or the UX team?
Depends on: 1221659
The issue mentioned on comment 5 is more likely part of bug 1187769 rather than the fading. I don't really have idea how the black could take 5s. Taking ~0.5s for transition is by design for better security. I guess this bug is for whether we really need the transition, instead of the performance issue which makes the black screen longer than design.
(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #6) > The issue mentioned on comment 5 is more likely part of bug 1187769 rather > than the fading. I don't really have idea how the black could take 5s. > Taking ~0.5s for transition is by design for better security. > > I guess this bug is for whether we really need the transition, instead of > the performance issue which makes the black screen longer than design. Even if there isn't any transition, aren't the drop warning and the black screen themselves serve the purpose of security? Can we make bug 1187769 less severe by starting the things we hide behind the black screen at the same time the transition took place? That would steal us 200ms. (Workaround for readers out there: I have been tweaking full-screen-api.transition-duration.* on my own profile. I realized setting it to "0 0" not just disable the transition but also the black screen as well. I don't think it looks particularly janky w/o the black screen and transition -- but I respect the comment made in bug 1160014 comment 7 so I am trying to find the middle ground here.)
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #7) > Can we make bug 1187769 less severe by starting the things we hide behind > the black screen at the same time the transition took place? That would > steal us 200ms. I tried and this won't work. flicker is very visible behind the transition.
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #8) > I tried and this won't work. flicker is very visible behind the transition. If we want to do this, we need to ensure that compositor wouldn't get update from the main thread when the transition starts.
(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #9) > (In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment > #8) > > I tried and this won't work. flicker is very visible behind the transition. > > If we want to do this, we need to ensure that compositor wouldn't get update > from the main thread when the transition starts. Thanks. I would probably try that... (In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #6) > Taking ~0.5s for transition is by design for better security. Who made that decision? I don't see any comment made explicitly on this in bug 1160014. Could we invite that person here so we could revisit the discussion? (In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #1) > Chrome does this, on OS X only, though. I checked and Chrome currently don't do this, instead it has the "bug" as described in bug 1177155. With the current situation here *and* bug 1187769 I would argue we are making things worse than leaving bug 1177155 visible to the user. A ~1/2s transition in/out & almost 1s of black screen is an uncomfortable jank as well...
I know with Photon they are putting a lot of effort into perceived performance and this really needs to be improved, exiting a full screen youtube video takes too long and it's making firefox seem/feel slow and laggy. I understand they need to keep some kind of fade for security reasons but it needs to be noticeably shorter in duration
(In reply to Will from comment #12) > I know with Photon they are putting a lot of effort into perceived > performance and this really needs to be improved, exiting a full screen > youtube video takes too long and it's making firefox seem/feel slow and > laggy. I understand they need to keep some kind of fade for security reasons > but it needs to be noticeably shorter in duration I agree that it needs to be short, and the transition animation is already short, which is only 400ms in total. The issue is probably that we hides the page behind the transition when the page hasn't changed back, and this wait time could be long. It would be helpful if we can have some profile showing what slows down the page reflow for unfullscreen.
From my local test, I don't see any lag with fullscreen / unfullscreen youtube video. The slowness may come from some background tabs (which would be mitigated by Quantum DOM effort), or some addons you use. You can probably try with a fresh profile or run Firefox with addons disabled, and see if that still happens.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.