1425887 - With tab animations disabled, closing current tab to switch to another will visibly show a blank page with spinner (causing flashing)

Status: NEW

(Firefox :: Tabbed Browser, defect, P3)

Description

[fireattack [:fireattack]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.24 Safari/537.36

Steps to reproduce:

Note: use recording software and record in high FPS and play in slow-mo to help you investigate if your eyes are not quick enough to catch it.

1. Set toolkit.cosmeticAnimations.enabled to false
2. Open multiple tabs, preferably complex ones
3. Close the current foreground tab, so it will switch to another one




Actual results:

When switching, there are a few frames that show a white background with "loading" icons in the middle.

The duration of that is not very long: about 1-3 frames, but very noticeable.It is basically flashing, especially when the website is dark. I won't say it's hazardous enough to cause epilepsy but still very unpleasant for eyes.

This GIF shows the bug: https://i.imgur.com/678aVTA.gif


Expected results:

It shouldn't show "load" no matter what. If the rendering is slow, it should wait until it's ready then switch.

Also, this doesn't happen when tab animation is on (toolkit.cosmeticAnimations.enabled = true). 

This GIF shows the transition when animation is ON: https://i.imgur.com/wanEmJT.gif

I don't get why the animation option will have any effect on the content canvas to begin with. As you can see, the animation is only on the tab part. The canvas content, when that option is off, will switch immediately when it's ready, without any intermediate "loading" page, thus no annoying flashing.


Note: this bug is not 100% reproducible, especially if you have a high-end PC with relatively light-weight profile. It also may or may not obvious for your eyes depending how sensitive you are. That's why I recommend to record it.

But I've reproduced it on at least three different computers before I report. I can reproduce it on 57 and newest Nightly.

Comment 1

[Lee Salzman [:lsalzman]]

This doesn't look like a graphics issue, per se. Moving this over to Firefox :: Tabbed Browser per Mike Conley's suggestion.

Comment 2

[fireattack [:fireattack]]

Thanks for the triage!

Comment 3

[Mike Conley (:mconley) (:⚙️) (PTO June 8 - 12)]

Putting this on dthayer's radar as a tentative fxperf:p2, as he's started to look into tab switch performance.

Comment 4

[Alex Thayer [:alexical] (she/her)]

This is a symptom of the fact that when a tab goes away for any reason (either by removing the tab or dragging the tab to a different window), we immediately display a spinner until the layers are ready. This is in contrast to normal tab switches, where we display the previous tab for up to 400ms while we wait for layers from the tab. In this case I think that the animation just hides the problem for a few frames which is long enough that the spinner doesn't have time to show up, since while we're animating the tab slide we continue to display the previous tab.

We need to make a decision about what to do in these two cases (tab removal and tabs being dragged to different windows) - do we continue showing the old tab's layers for up to 400ms like we do with normal tab switches, or do we just show a blank window? I'm not sure who's best able to make this decision - thoughts mconley?

Comment 5

[Mike Conley (:mconley) (:⚙️) (PTO June 8 - 12)]

(In reply to Doug Thayer [:dthayer] from comment #4)
> We need to make a decision about what to do in these two cases (tab removal
> and tabs being dragged to different windows) - do we continue showing the
> old tab's layers for up to 400ms like we do with normal tab switches, or do
> we just show a blank window? I'm not sure who's best able to make this
> decision - thoughts mconley?

I think we'd want to show the old layers - otherwise, we get this flashing effect on the eyes. And hopefully, as we improve tab switch performance, the amount of time seeing those old layers will go down.

Comment 6

[Alex Thayer [:alexical] (she/her)]

Got a patch working for this, but it breaks ~500 tests and I don't have a great way out of that conundrum. So I'm putting this on hold. Fixing the tests would be fairly mechanical, but I think there are bigger things to do right now regarding tab switch spinners.

Comment 7

[:Gijs (he/him)]

Mike, would this actually be limited to cases where animations are turned off? I guess I'm not sure off-hand how that would impact this case. If it isn't limited to those cases, perhaps the perf impact of this should be bumped?

Comment 8

[Mike Conley (:mconley) (:⚙️) (PTO June 8 - 12)]

It also impacts the tab drag in / drag out case. I agree, let's up the impact slightly.

Comment 9

[Frank Doty [:fdoty]]

:mconley is this pref still available? we're not seeing any indication of it being present