1237654 - [e10s] browser.tabs.animate/toolkit.cosmeticAnimations.enabled = false - makes black (Lin) or white (Win) blinks and flashes when switching (Lin) or closing (Win) tabs

Status: RESOLVED WORKSFORME

(Firefox :: Tabbed Browser, defect, P3)

Description

[Mike Conley (:mconley) (:⚙️)]

According to billm, he sometimes sees a black flash when switching tabs on his Linux machine with e10s enabled.

I have not yet been able to reproduce this on my Ubuntu VM. Does anybody else see this?

Comment 1

[Mike Conley (:mconley) (:⚙️)]

(Spun off from bug 1159827)

Comment 2

[Liviu Cirdei]

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

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

Can not reproduce on Aurora 46 and Nightly 47 (Ubuntu 15.04). 
@Bill, are you still see this issue?

Comment 3

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I just updated to Ubuntu 15.10. I'll see if it still reproduces.

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

If anything the problem is worse in 15.10.

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I tracked this down somewhat. It turns out it only reproduces when I have the Vertical Tabs add-on installed. However, I'm concerned that there might be other circumstances where this could happen. Also, I want to fix it for my own benefit.

One big change with Vertical tabs is that it sets browser.tabs.animate to false. If I create a fresh profile (without Vertical Tabs) and set this pref to false, then I can reproduce the behavior where the new tab page appears briefly when closing a tab. This happens because of this branch:
https://dxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#2146
What concerns me is that we can also take this branch for several other reasons that are more common than Vertical Tabs.

The flash of black only reproduces with Vertical Tabs and I haven't figured out why yet. These two seem like separate issues, so we might want to split the new tab page problem into a separate bug. It probably should have a somewhat higher priority.

Comment 8

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

STR:
1. Open about:config and set "browser.tabs.animate" to "false"
2. Restart Firefox
3. Open 10x https://pl.ogame.gameforge.com/ in tabs in one window
4. Start closing tabs to see white blinks and flashes


e10=on - screencast.mp4 (214.88 KB, video/mp4)
https://bugzilla.mozilla.org/attachment.cgi?id=8742491

e10s=off - screencast.mp4 (102.74 KB, video/mp4)
https://bugzilla.mozilla.org/attachment.cgi?id=8742492

Comment 9

[Dão Gottwald [:dao]]

(In reply to Bill McCloskey (:billm) from comment #5)
> The flash of black only reproduces with Vertical Tabs and I haven't figured
> out why yet. These two seem like separate issues, so we might want to split
> the new tab page problem into a separate bug. It probably should have a
> somewhat higher priority.

For the record, that would be bug 1247137.

Comment 10

[Aris]

Anyone tried to keep browser.tabs.animate on true, but kill the animation via css?

Does using something like this make any difference:

#tabbrowser-tabs,
#tabbrowser-tabs *,
.tabbrowser-tab,
.tabbrowser-tab * {
  transition: unset !important;
}

Comment 11

[Jim Mathies [:jimm]]

Chris, any chance you can help us out here by pulling the current data from this on nightly?

Comment 12

[Jim Mathies [:jimm]]

gah, wrong bug.

Comment 13

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(In reply to Aris from comment #10)
> Anyone tried to keep browser.tabs.animate on true, but kill the animation
> via css?
> 
> Does using something like this make any difference:
> 
> #tabbrowser-tabs,
> #tabbrowser-tabs *,
> .tabbrowser-tab,
> .tabbrowser-tab * {
>   transition: unset !important;
> }

Thank you very much for the workaround!
Looks partially fixed.

Your workaround reduce the frequency of these annoying "eye-cancer" white flashes and blinks here by 99%.
In very rare cases sometimes I can briefly see the page re-rendering or maybe they're these black flashes and blinks seen on Linux, but it' probably other bug related to rendering with fast tab switching and this annoying spinner traced in bug #1131167 & bug #1135719.

The only downside of this workaround is that, that's it breaks bug #465086.

Comment 14

[Aris]

@Virtual_ManPL

What about keeping the transition, but reducing its duration to a minimum?

#tabbrowser-tabs,
#tabbrowser-tabs *,
.tabbrowser-tab,
.tabbrowser-tab * {
  transition: 0.01s !important;
  transition-duration: 0.01s !important;
}

Comment 15

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(In reply to Aris from comment #14)
> @Virtual_ManPL
> 
> What about keeping the transition, but reducing its duration to a minimum?
> 
> #tabbrowser-tabs,
> #tabbrowser-tabs *,
> .tabbrowser-tab,
> .tabbrowser-tab * {
>   transition: 0.01s !important;
>   transition-duration: 0.01s !important;
> }

Thank you very much for next the workaround!

No more annoying "eye-cancer" white flashes and blinks.

Compared to the previous workaround, this one doesn't break bug #465086 and no more page re-rendering and these black flashes and blinks, which could be seen with previous workaround.

There are 2 downsides of this workaround:
- "Menu Bar" without any items is seen on each new windows (pressing 2 times Alt keyboard button hides this blank bar)
- it's still CPU resource hungry, compared to no animated opening/closing tabs (due to enabled "browser.tabs.animate")

Comment 16

[:shell escalante]

removing from add-on blocking since gfx area

Comment 18

[Edouard Oger [:eoger]]

Someone reported this on the Tab Center Redux issues tracker: https://github.com/eoger/tabcenter-redux/issues/222
I see in comment 5 that Bill mentioned a Vertical Tabs extension, which is also the case here.

Comment 19

[YUKI "Piro" Hiroshi]

This is also reported at Tree Style Tab's issue tracker.
https://github.com/piroor/treestyletab/issues/1491

Comment 20

[atlanto]

Still getting white flashing on 61.0a1(build 20180319100039) in this day.

Although I don't know old days and I'm not sure, I'm suspecting this calling.
https://hg.mozilla.org/mozilla-central/file/38f424da56206f0946ddd01b3c9b1ce5bf195739/browser/base/content/tabbrowser.js#l2657
>      this._endRemoveTab(aTab);
https://hg.mozilla.org/mozilla-central/file/38f424da56206f0946ddd01b3c9b1ce5bf195739/browser/base/content/tabbrowser.js#l2917
>    // In the multi-process case, it's possible an asynchronous tab switch
>    // is still underway. If so, then it's possible that the last visible
>    // browser is the one we're in the process of removing. There's the
>    // risk of displaying preloaded browsers that are at the end of the
>    // deck if we remove the browser before the switch is complete, so
>    // we alert the switcher in order to show a spinner instead.
>    if (this._switcher) {
>      this._switcher.onTabRemoved(aTab);
>    }

It seems that this invocation while tab-switching(?) is in progress(?) inside AsyncTabSwitcher causes ununderstandable result, displaying spinner and hide it. (I'm not understanding what AsyncTabSwitcher is doing)

Delayed calling to _endRemoveTab(aTab) makes AsyncTabSwitcher do nothing(for this event), so no flashing occured. (not a solution, just in case)

Comment 21

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Updating preference name per last change in Firefox.

Comment 22

[Jason Mechelynck]

Is there any easy work around for this other than css fix or timeline to fix this?

Comment 23

[Mike Conley (:mconley) (:⚙️)]

(In reply to Jason Mechelynck from comment #22)
> Is there any easy work around for this other than css fix or timeline to fix
> this?

Bug 1176019 might help with this in the majority of cases, but it's still early days there.

Comment 24

[Jason Mechelynck]

(In reply to Mike Conley (:mconley) (:⚙️) (Catching up on needinfos / reviews) from comment #23)
> (In reply to Jason Mechelynck from comment #22)
> > Is there any easy work around for this other than css fix or timeline to fix
> > this?
> 
> Bug 1176019 might help with this in the majority of cases, but it's still
> early days there.

Is there any remote chance this will get fixed soon?

Bug 1176019 landed and then backed out without ever fixing the problem.

> Bug 1176019 might help with this in the majority of cases

So that's not true anymore

Comment 25

[Mike Conley (:mconley) (:⚙️)]

(In reply to Jason Mechelynck from comment #24)
> Is there any remote chance this will get fixed soon?

It's possible. I've queued it for triage.

Comment 26

[Jason Mechelynck]

(In reply to Mike Conley (:mconley) (:⚙️) (Catching up on needinfos / reviews) from comment #25)
> (In reply to Jason Mechelynck from comment #24)
> > Is there any remote chance this will get fixed soon?
> 
> It's possible. I've queued it for triage.

Good to see that.

Comment 27

[Jason Mechelynck]

see 
Bug 1442573

Comment 28

[:Gijs (he/him)]

This is unfortunately probably p3 given this only happens when the pref is flipped, and is not trivial to fix "properly".

This should be fixable by essentially delaying the closing of the tab until we've warmed layers for the to-be-selected tab. We already start warming layers once you hover the close button (as of Firefox 59, https://bugzilla.mozilla.org/show_bug.cgi?id=1430292 ) so this should help for mouse users (it does in my quick testing on my Windows 10 machine). We're also investigating LRU-based caching of layers, which will also help as noted in this bug.

(In reply to Jason Mechelynck from comment #24)
> Bug 1176019 landed and then backed out without ever fixing the problem.

That's that bug, but it didn't get backed out, it was disabled - you could try running with it enabled by setting the browser.tabs.remote.tabCacheSize pref to a positive value; there may be some side effects (e.g. bug 1464712). Maybe that can be a help in the immediate term.

Fixing this by delaying the call to _endRemoveTab would be a bit tricky. A few things to keep in mind for whoever ends up working on this (pretty sure we'd take patches as well if we don't get to it first!):
- we'd have to make sure it didn't make it impossible to close tabs if the next tab's content process was hung (ie there'd have to be some kind of timeout for the wait for the layer tree)
- we should close the tab if a tabswitch happens before we get a layer tree for the tab we were going to switch to (ie if the user tabswitches immediately after closing a tab, that'd "race" with waiting to close the original tab)
- tests. All the current tests expect invoking removeTab() to be immediate because there's no animation involved, and thus no waiting. That may be a tricky thing to change. Of course, we could add an override of sorts specific to tests, but that'd mean we wouldn't be testing what we ship, which has its own issues.

Comment 29

[Jason Mechelynck]

(In reply to :Gijs (he/him) from comment #28)
> This is unfortunately probably p3 given this only happens when the pref is
> flipped, and is not trivial to fix "properly".
> 
> This should be fixable by essentially delaying the closing of the tab until
> we've warmed layers for the to-be-selected tab. We already start warming
> layers once you hover the close button (as of Firefox 59,
> https://bugzilla.mozilla.org/show_bug.cgi?id=1430292 ) so this should help
> for mouse users (it does in my quick testing on my Windows 10 machine).
> We're also investigating LRU-based caching of layers, which will also help
> as noted in this bug.
> 
> (In reply to Jason Mechelynck from comment #24)
> > Bug 1176019 landed and then backed out without ever fixing the problem.
> 
> That's that bug, but it didn't get backed out, it was disabled - you could
> try running with it enabled by setting the browser.tabs.remote.tabCacheSize
> pref to a positive value; there may be some side effects (e.g. bug 1464712).
> Maybe that can be a help in the immediate term.
> 
> Fixing this by delaying the call to _endRemoveTab would be a bit tricky. A
> few things to keep in mind for whoever ends up working on this (pretty sure
> we'd take patches as well if we don't get to it first!):
> - we'd have to make sure it didn't make it impossible to close tabs if the
> next tab's content process was hung (ie there'd have to be some kind of
> timeout for the wait for the layer tree)
> - we should close the tab if a tabswitch happens before we get a layer tree
> for the tab we were going to switch to (ie if the user tabswitches
> immediately after closing a tab, that'd "race" with waiting to close the
> original tab)

Well enabled it but no difference.

maybe because using kb to close tab 
but switching tabs even very quickly with KB doesn't create the flicker so guessing that it has something to do with the way tab closing is handled instead of caching of tabs etc

Comment 30

[Jason Mechelynck]

Firefox Performance Update #10

Browser Adjustment Project (In-Progress by Gijs Kruitbosch)

This is a research project to find ways that Firefox can classify the hardware it’s running on, which should make it easier for the browser to make informed decisions on how to deal with things like CPU scheduling, thread and process priority, graphics and UI optimizations, and memory reclamation strategies. This project is still in its early days, but Gijs has already identified prior art and research that we can build upon, and is looking at lightweight ways we can assign grades to a user’s CPU, disk, and graphics hardware. Then the plan is to try hooking that up to the toolkit.cosmeticAnimations pref, to test disabling those animations on weaker hardware. He’s also exploring ways in which the user can override these measurements in the event that they want to bypass the defaults that we choose for each environment.

What is the bug number and will this bug be fixed first?

(In reply to :Gijs (he/him) from comment #28)
> This is unfortunately probably p3 given this only happens when the pref is
> flipped, and is not trivial to fix "properly".
> 
> This should be fixable by essentially delaying the closing of the tab until
> we've warmed layers for the to-be-selected tab. We already start warming
> layers once you hover the close button (as of Firefox 59,
> https://bugzilla.mozilla.org/show_bug.cgi?id=1430292 ) so this should help
> for mouse users (it does in my quick testing on my Windows 10 machine).
> We're also investigating LRU-based caching of layers, which will also help
> as noted in this bug.
> 
> (In reply to Jason Mechelynck from comment #24)
> > Bug 1176019 landed and then backed out without ever fixing the problem.
> 
> That's that bug, but it didn't get backed out, it was disabled - you could
> try running with it enabled by setting the browser.tabs.remote.tabCacheSize
> pref to a positive value; there may be some side effects (e.g. bug 1464712).
> Maybe that can be a help in the immediate term.
> 
> Fixing this by delaying the call to _endRemoveTab would be a bit tricky. A
> few things to keep in mind for whoever ends up working on this (pretty sure
> we'd take patches as well if we don't get to it first!):
> - we'd have to make sure it didn't make it impossible to close tabs if the
> next tab's content process was hung (ie there'd have to be some kind of
> timeout for the wait for the layer tree)
> - we should close the tab if a tabswitch happens before we get a layer tree
> for the tab we were going to switch to (ie if the user tabswitches
> immediately after closing a tab, that'd "race" with waiting to close the
> original tab)
> - tests. All the current tests expect invoking removeTab() to be immediate
> because there's no animation involved, and thus no waiting. That may be a
> tricky thing to change. Of course, we could add an override of sorts
> specific to tests, but that'd mean we wouldn't be testing what we ship,
> which has its own issues.

FF63b20180725103029

Whit pages with images or tabs
this flickering can be seen without the pref flip.


(In reply to Mike Conley (:mconley) (:⚙️) (PTO Jul 24th-Aug 6th)) from comment #25)
> (In reply to Jason Mechelynck from comment #24)
> > Is there any remote chance this will get fixed soon?
> 
> It's possible. I've queued it for triage.

So now any chance this will be fixed?

Not being rude just tired of being provided with vague info or false info.
It's been 3yrs guys!

Comment 31

[:Gijs (he/him)]

(In reply to Jason Mechelynck from comment #30)
> Firefox Performance Update #10
> 
> Browser Adjustment Project (In-Progress by Gijs Kruitbosch)
> 
> What is the bug number

I haven't filed a tracking bug yet, we're still researching what the best way forward would be. bug 1475242 is gathering some data to support this project, but has no bearing on any of this given it's literally about analysing telemetry data, not about any Firefox changes. I guess I could file a placeholder bug...

> will this bug be fixed first?

I don't know.

> (In reply to :Gijs (he/him) from comment #28)
> FF63b20180725103029
> 
> Whit pages with images or tabs
> this flickering can be seen without the pref flip.

This is covered by bug 1442573, right? If you can easily reproduce that bug, you could help by using mozregression to find a regression window for when something broke there, and posting it on that bug.

> (In reply to Mike Conley (:mconley) (:⚙️) (PTO Jul 24th-Aug 6th)) from
> comment #25)
> > (In reply to Jason Mechelynck from comment #24)
> > > Is there any remote chance this will get fixed soon?
> > 
> > It's possible. I've queued it for triage.
> 
> So now any chance this will be fixed?
> 
> Not being rude just tired of being provided with vague info or false info.

I think there's a few different ways this breaks; I posted pointers to what seems to help with the issue I could reproduce myself (for which I also landed a fix in bug 1472230). I don't think we fully understand the cause of what you're seeing (which must be different from the cause of what I'm seeing), but that doesn't mean that what we're posting is "vague" or "false", and insinuating that's what we're doing isn't productive.

> It's been 3yrs guys!

Has it? You only CC'd yourself on this bug in April of this year. How long have you been seeing this? If it's actually been there since the dawn of e10s then there's probably no point finding a regression window. If the problem has become worse for you more recently, then finding a regression window is more helpful.

More generally, pointing out "it's been 3 years" isn't helpful. Priority is a combination of a lot of factors. We don't fix bugs in a strict first-filed-first-fixed order, or we'd be have to ignore much more pressing recent stability/performance issues.

Comment 32

[Jason Mechelynck]

(In reply to :Gijs (he/him) from comment #31)
> (In reply to Jason Mechelynck from comment #30)
> > Firefox Performance Update #10
> > 
> > Browser Adjustment Project (In-Progress by Gijs Kruitbosch)
> > 
> > What is the bug number
> 
> I haven't filed a tracking bug yet, we're still researching what the best
> way forward would be. bug 1475242 is gathering some data to support this
> project, but has no bearing on any of this given it's literally about
> analysing telemetry data, not about any Firefox changes. I guess I could
> file a placeholder bug...


Lets us know

> > will this bug be fixed first?
> 
> I don't know.


:(

> > (In reply to :Gijs (he/him) from comment #28)
> > FF63b20180725103029
> > 
> > Whit pages with images or tabs
> > this flickering can be seen without the pref flip.
> 
> This is covered by bug 1442573, right? If you can easily reproduce that bug,
> you could help by using mozregression to find a regression window for when
> something broke there, and posting it on that bug.


Tried it and saw someone else also try it with no luck other than in it was introduced in Fx41 - Fx43 iirc.

> > (In reply to Mike Conley (:mconley) (:⚙️) (PTO Jul 24th-Aug 6th)) from
> > comment #25)
> > > (In reply to Jason Mechelynck from comment #24)
> > > > Is there any remote chance this will get fixed soon?
> > > 
> > > It's possible. I've queued it for triage.
> > 
> > So now any chance this will be fixed?
> > 
> > Not being rude just tired of being provided with vague info or false info.
> 
> I think there's a few different ways this breaks; I posted pointers to what
> seems to help with the issue I could reproduce myself (for which I also
> landed a fix in bug 1472230). I don't think we fully understand the cause of
> what you're seeing (which must be different from the cause of what I'm
> seeing), but that doesn't mean that what we're posting is "vague" or
> "false", and insinuating that's what we're doing isn't productive.
> 
> > It's been 3yrs guys!
> 
> Has it? You only CC'd yourself on this bug in April of this year. How long
> have you been seeing this? If it's actually been there since the dawn of
> e10s then there's probably no point finding a regression window. If the
> problem has become worse for you more recently, then finding a regression
> window is more helpful.


No cc'ed myself when it looked like the problem was found out and hopefully this was the right bug

> More generally, pointing out "it's been 3 years" isn't helpful. Priority is
> a combination of a lot of factors. We don't fix bugs in a strict
> first-filed-first-fixed order, or we'd be have to ignore much more pressing
> recent stability/performance issues.

Replied earlier in the post.
Found the comment

https://bugzilla.mozilla.org/show_bug.cgi?id=1442573#c9

Is this not a priority bug?
Also see
https://bugzilla.mozilla.org/show_bug.cgi?id=1442573#c30

Comment 33

[:Gijs (he/him)]

(In reply to Jason Mechelynck from comment #32)
> Is this not a priority bug?
> Also see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1442573#c30

I think at this point the 2 bugs contain a big mix of issues. They all seem to have to do with us switching tabs and not having layers for the next one, thus showing the tab spinner, which by default has the window background (white on almost all Windows themes, can be black on Linux). But the specific circumstances under which they happen differ a lot between the different commenters. Unfortunately, that means any 1 fix for 1 of those circumstances is unlikely to fix it for everyone else.

Reducing tab spinners is a priority. How soon that'll change anything for your usecase is hard to say. This bug is already confused because it mentions both switching tabs and closing tabs, and the cause for a tab spinner shown in one of those cases isn't likely to be the same as in the other cases. It also mentions the pref, which you're saying you haven't changed and you're still seeing spinners.


Fundamentally, whenever we switch to a new tab (either because the user switches tabs or because the user closes a tab, thus causing us to switch to the next remaining tab), we need to ask the content processes to display that content (where it didn't previously). When we switch tabs like this, there are 2 competing aims:

1) show the new content as quickly as possible, and avoid showing the tab spinner screen (the white/black "flash")
2) don't delay the tab switch / closure indefinitely - if the content process is busy or hung, we still want to show the user that they did close/switch a tab, because otherwise they might be confused about which tabs are/aren't closed or what the current tab is.

To accomplish (2) there's a deadline that the parent process sets for the content process to send it the graphics data. If the content process doesn't meet the deadline, we show the spinner (causes the white/black "flash").

The crux here is that it's impossible to only do (1) (ie never show the tab spinner) without giving up on (2), which we don't want to do - if the content process of the new tab is hung, the main browser UI needs to remain responsive. The parent process has no way of figuring out if the process is hung or just really really busy - all it can do is display UI that says "hey, we're a bit busy here", and hope that the content process recovers soon. If it spends *really* long not responding, we'll offer the user UI to restart the content process, but that's not a point we reach in any of these bugs.

So we can't "just" make the spinner flashes go away or "just" prioritize "this" bug. It's a hard problem, with a lot of different factors, and fixing things for one person won't necessarily fix it for everyone else because they're seeing the spinner for different reasons. A bit like fixing 1 issue that crashes the browser doesn't mean the browser magically never ever crashes - there's more than 1 way to crash the browser, even if the symptoms (crash!) look the same.



All the steps to reproduce in this bug and bug 1442573 include steps that make it harder for us to accomplish (1) and (2), and therefore increase the chances of seeing the spinner (black/white "flash"). In no particular order:

a) the animation prefs mentioned in the summary of this bug mean we try to switch tabs immediately when closing a tab. If there's an animation, that gives us extra time to ask the content process for the new layers for the new tab, which means you don't see a spinner. Without the animation, there's less time and so it's more likely you see a spinner.
b) the attached separate prefs.js file from "u614034" in bug 1442573 explicitly disables browser.tabs.remote.warmup.enabled. This is the default in release/beta while we iron out issues, but on nightly the default is for it to be enabled. This turns on a feature where we proactively get graphics/layer data from tabs you're about to switch to, which also helps. bug 1434651 tracks uplifting this to release.
c) the attached "error.zip" file in bug 1442573 sets the number of content processes to 1. This makes it much more likely that two tabs share a content process, and so switching/closing tabs means 1 content process is busy with both getting rid of the stuff in the old tab (especially if it was closed, meaning we need to free up the relevant bits of memory etc.) as well as trying to get the new tab ready, which increases the chances it doesn't meet the "deadline", which means we show a spinner ("flash").
d) switching/closing tabs with the keyboard means the parent process has less warning about which tab you're about to switch to. If you switch with the mouse, we get at least a few ms warning - which is usually enough! - because the mouse hovers or mousedown-s on something, and we only active the close button or close the tab once you actually complete that action. While you're hovering/mousedown'ing, the parent process already tells the expected "next" tab to get its stuff ready.

This bug has information for how to fix (a) for closing tabs with the animation disabled. It may also help in cases where the animation *is* enabled; I don't know off-hand.

(b) already has separate bugs filed.

For (d), the projected solution is using bug 1176019 to cache tabs on a last used basis. Firefox can't guess you're about to close/switch tabs, though I suppose another thing we could try is detecting ctrl/cmd-keypresses and warming up the next and previous tab just to be sure. I filed bug 1478703 for this.

(c) is apparently based on what you're seeing. I would suggest resetting the dom.ipc.processCount pref and seeing if that helps at all. Otherwise, hopefully one or more of the other bugs here will help, as well as a general focus on performance that reduces memory/CPU usage in the content process, which means it's more responsive, which means we get layers sooner, which means you see the spinners/flashes less often.

Comment 34

[Jason Mechelynck]

(In reply to :Gijs (he/him) from comment #33)
> (In reply to Jason Mechelynck from comment #32)
> > Is this not a priority bug?
> > Also see
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1442573#c30
> 

Hi there, there seems to be some confusion so let me explain
the pref file provided there was only to show the issue easily to the test and also happens on regular profile, so the issue is there.

> I think at this point the 2 bugs contain a big mix of issues. They all seem
> to have to do with us switching tabs and not having layers for the next one,
> thus showing the tab spinner, which by default has the window background
> (white on almost all Windows themes, can be black on Linux). But the
> specific circumstances under which they happen differ a lot between the
> different commenters. Unfortunately, that means any 1 fix for 1 of those
> circumstances is unlikely to fix it for everyone else.
> 

Partly incorrect.
If it was the layers not being ready in time and that caused the flashes then the same issue would have occurred when using ctrl+tab to switch tabs,
but it doesn't happen. It only happens while closing the tabs via KB or Mouse.
The circular spinners are never seen so that is not the problem, as soon as the tab is closed the tb with direct images in it or page like imagery creates a white flash for a second or two then show the page properly, ctrl+tab does not create a flash but just renders the tab immediately and properly so layers not being ready is simply not true because tested with tab warming disabled as well as enabled and both work fine while switching but cause flash while closing.


> Reducing tab spinners is a priority. How soon that'll change anything for
> your use case is hard to say. This bug is already confused because it
> mentions both switching tabs and closing tabs, and the cause for a tab
> spinner shown in one of those cases isn't likely to be the same as in the
> other cases. It also mentions the pref, which you're saying you haven't
> changed and you're still seeing spinners.
> 

No only seeing flashes while closing tabs not when Ctrl+tab through them, this was the case from the start.


> Fundamentally, whenever we switch to a new tab (either because the user
> switches tabs or because the user closes a tab, thus causing us to switch to
> the next remaining tab), we need to ask the content processes to display
> that content (where it didn't previously). When we switch tabs like this,
> there are 2 competing aims:
> 
> 1) show the new content as quickly as possible, and avoid showing the tab
> spinner screen (the white/black "flash")
> 2) don't delay the tab switch / closure indefinitely - if the content
> process is busy or hung, we still want to show the user that they did
> close/switch a tab, because otherwise they might be confused about which
> tabs are/aren't closed or what the current tab is.
> 

Again not the issue here if correct,
Ctrl+tab should also if affected if the process is busy or hung same as closing the tab,
but only the later causes the issue so layers are ready and process are working fine.

> To accomplish (2) there's a deadline that the parent process sets for the
> content process to send it the graphics data. If the content process doesn't
> meet the deadline, we show the spinner (causes the white/black "flash").
>

Then why does this ONLY happen while closing and not switching between tabs
 
> The crux here is that it's impossible to only do (1) (ie never show the tab
> spinner) without giving up on (2), which we don't want to do - if the
> content process of the new tab is hung, the main browser UI needs to remain
> responsive. The parent process has no way of figuring out if the process is
> hung or just really really busy - all it can do is display UI that says
> "hey, we're a bit busy here", and hope that the content process recovers
> soon. If it spends *really* long not responding, we'll offer the user UI to
> restart the content process, but that's not a point we reach in any of these
> bugs.
Same as above.

> So we can't "just" make the spinner flashes go away or "just" prioritize
> "this" bug. It's a hard problem, with a lot of different factors, and fixing
> things for one person won't necessarily fix it for everyone else because
> they're seeing the spinner for different reasons. A bit like fixing 1 issue
> that crashes the browser doesn't mean the browser magically never ever
> crashes - there's more than 1 way to crash the browser, even if the symptoms
> (crash!) look the same.
> 
> 
> 
> All the steps to reproduce in this bug and bug 1442573 include steps that
> make it harder for us to accomplish (1) and (2), and therefore increase the
> chances of seeing the spinner (black/white "flash"). In no particular order:
> 
> a) the animation prefs mentioned in the summary of this bug mean we try to
> switch tabs immediately when closing a tab. If there's an animation, that
> gives us extra time to ask the content process for the new layers for the
> new tab, which means you don't see a spinner. Without the animation, there's
> less time and so it's more likely you see a spinner.

But why only if closing tabs? and not when switching, both require layers to be ready and process not to be hung or busy.
But one works as it should the other does not.

> b) the attached separate prefs.js file from "u614034" in bug 1442573
> explicitly disables browser.tabs.remote.warmup.enabled. This is the default
> in release/beta while we iron out issues, but on nightly the default is for
> it to be enabled. This turns on a feature where we proactively get
> graphics/layer data from tabs you're about to switch to, which also helps.
> bug 1434651 tracks uplifting this to release.
> c) the attached "error.zip" file in bug 1442573 sets the number of content
> processes to 1. This makes it much more likely that two tabs share a content
> process, and so switching/closing tabs means 1 content process is busy with
> both getting rid of the stuff in the old tab (especially if it was closed,
> meaning we need to free up the relevant bits of memory etc.) as well as
> trying to get the new tab ready, which increases the chances it doesn't meet
> the "deadline", which means we show a spinner ("flash").
> d) switching/closing tabs with the keyboard means the parent process has
> less warning about which tab you're about to switch to. If you switch with
> the mouse, we get at least a few ms warning - which is usually enough! -
> because the mouse hovers or mousedown-s on something, and we only active the
> close button or close the tab once you actually complete that action. While
> you're hovering/mousedown'ing, the parent process already tells the expected
> "next" tab to get its stuff ready.
 
 Like said in the beginning the OP's profile is just as start, this happens with default too.
 
> This bug has information for how to fix (a) for closing tabs with the
> animation disabled. It may also help in cases where the animation *is*
> enabled; I don't know off-hand.
> 
> (b) already has separate bugs filed.
> 
> For (d), the projected solution is using bug 1176019 to cache tabs on a last
> used basis. Firefox can't guess you're about to close/switch tabs, though I
> suppose another thing we could try is detecting ctrl/cmd-keypresses and
> warming up the next and previous tab just to be sure. I filed bug 1478703
> for this.

That is not the problem as said above.
The tabs don't flash while switching only while closing.
So that bug might help speed up things but that's not the fundamental problem here.


> (c) is apparently based on what you're seeing. I would suggest resetting the
> dom.ipc.processCount pref and seeing if that helps at all. Otherwise,
> hopefully one or more of the other bugs here will help, as well as a general
> focus on performance that reduces memory/CPU usage in the content process,
> which means it's more responsive, which means we get layers sooner, which
> means you see the spinners/flashes less often.

Okay then please try out something and post your findings

create a new profile and open 20 tabs with images,
or use the session added by OP

A)ctrl-tabs between them as fast as you can,
B)now close them one by one as soon as images are displayed.

In A you wont see any flashes but in B you might see.

If you still can see the issue then there is a simple way to show you the flashes 

in FF63
set this to true

browser.tabs.remote.separatePrivilegedContentProcess

create a new profile and open 20 tabs with images,
or use the session added by OP

A)ctrl-tabs between them as fast as you can,
B)now close them one by one as soon as images are displayed.

now the flashes should be seem easily while closing tab(this is the problem)

FYi just trying to help and make FF better,
Since this problem is reproducible easily on 4 different laptops with amd and intel.
If you can't reproduce it it doesn't mean it's not happening.
@mike assumption might be true that this is a async tab switching issue and not that the next tab layers are not ready.

Comment 35

[:Gijs (he/him)]

(In reply to Jason Mechelynck from comment #34)
> (In reply to :Gijs (he/him) from comment #33)
> > I think at this point the 2 bugs contain a big mix of issues. They all seem
> > to have to do with us switching tabs and not having layers for the next one,
> > thus showing the tab spinner, which by default has the window background
> > (white on almost all Windows themes, can be black on Linux). But the
> > specific circumstances under which they happen differ a lot between the
> > different commenters. Unfortunately, that means any 1 fix for 1 of those
> > circumstances is unlikely to fix it for everyone else.
> 
> Partly incorrect.
> If it was the layers not being ready in time and that caused the flashes
> then the same issue would have occurred when using ctrl+tab to switch tabs,

Not necessarily - closing the tab will cause more activity (running beforeunload + unload handlers, GC'ing a bunch of stuff, etc.) in the process in which we're closing tabs, as well as the parent process (removing the tab, the browser, all the bookkeeping for both, session store work, etc.) than switching tabs, thus making it more likely for you to see that.

> but it doesn't happen.

It does for me and it does in the screencast in https://bug1442573.bmoattachments.org/attachment.cgi?id=8961050 , see e.g. at about 0:08. If you pause the video you can clearly see the spinner at the bottom of the screen.

> The circular spinners are never seen so that is not the problem,

Can you post a screencast of what you're seeing, then?

> > Reducing tab spinners is a priority. How soon that'll change anything for
> > your use case is hard to say. This bug is already confused because it
> > mentions both switching tabs and closing tabs, and the cause for a tab
> > spinner shown in one of those cases isn't likely to be the same as in the
> > other cases. It also mentions the pref, which you're saying you haven't
> > changed and you're still seeing spinners.
> > 
> 
> No only seeing flashes while closing tabs not when Ctrl+tab through them,
> this was the case from the start.

But this is clearly not what everyone here is seeing. In particular, in comment #0 when the bug was reported, it was specifically about *switching* (not closing) tabs. Hence my comment that these bugs contain a mix of issues, all of which have to do with switching tabs (either by the user switching tabs, or by the user closing the selected tab thus causing us to switch to the next tab).

> > (c) is apparently based on what you're seeing. I would suggest resetting the
> > dom.ipc.processCount pref and seeing if that helps at all. Otherwise,
> > hopefully one or more of the other bugs here will help, as well as a general
> > focus on performance that reduces memory/CPU usage in the content process,
> > which means it's more responsive, which means we get layers sooner, which
> > means you see the spinners/flashes less often.
> 
> Okay then please try out something and post your findings
> 
> create a new profile and open 20 tabs with images,
> or use the session added by OP

I assume you mean the zipfile on bug 1442573 you added, as the OP here didn't add a session? I tried that before posting my earlier comment and saw flashes for both cases.

Comment 36

[Jason Mechelynck]

(In reply to :Gijs (he/him) from comment #35)
> (In reply to Jason Mechelynck from comment #34)
> > (In reply to :Gijs (he/him) from comment #33)
> > > I think at this point the 2 bugs contain a big mix of issues. They all seem
> > > to have to do with us switching tabs and not having layers for the next one,
> > > thus showing the tab spinner, which by default has the window background
> > > (white on almost all Windows themes, can be black on Linux). But the
> > > specific circumstances under which they happen differ a lot between the
> > > different commenters. Unfortunately, that means any 1 fix for 1 of those
> > > circumstances is unlikely to fix it for everyone else.
> > 
> > Partly incorrect.
> > If it was the layers not being ready in time and that caused the flashes
> > then the same issue would have occurred when using ctrl+tab to switch tabs,
> 
> Not necessarily - closing the tab will cause more activity (running
> beforeunload + unload handlers, GC'ing a bunch of stuff, etc.) in the
> process in which we're closing tabs, as well as the parent process (removing
> the tab, the browser, all the bookkeeping for both, session store work,
> etc.) than switching tabs, thus making it more likely for you to see that.
> 

Okay but tested again with default profile and no spinners.


> > but it doesn't happen.
> 
> It does for me and it does in the screen cast in
> https://bug1442573.bmoattachments.org/attachment.cgi?id=8961050 , see e.g.
> at about 0:08. If you pause the video you can clearly see the spinner at the
> bottom of the screen.
> 

Sorry missed that but that's not the case here.


> > The circular spinners are never seen so that is not the problem,
> 
> Can you post a screencast of what you're seeing, then?
> 

How to do it in windows? and keep size small for attachment?

> > > Reducing tab spinners is a priority. How soon that'll change anything for
> > > your use case is hard to say. This bug is already confused because it
> > > mentions both switching tabs and closing tabs, and the cause for a tab
> > > spinner shown in one of those cases isn't likely to be the same as in the
> > > other cases. It also mentions the pref, which you're saying you haven't
> > > changed and you're still seeing spinners.
> > > 
> > 
> > No only seeing flashes while closing tabs not when Ctrl+tab through them,
> > this was the case from the start.
> 
> But this is clearly not what everyone here is seeing. In particular, in
> comment #0 when the bug was reported, it was specifically about *switching*
> (not closing) tabs. Hence my comment that these bugs contain a mix of
> issues, all of which have to do with switching tabs (either by the user
> switching tabs, or by the user closing the selected tab thus causing us to
> switch to the next tab).
> 

Switching also creates the issue but not as often as closing, For STR asked to close tabs
to see what actually is happening since devs were not able to reproduce it properly.

> > > (c) is apparently based on what you're seeing. I would suggest resetting the
> > > dom.ipc.processCount pref and seeing if that helps at all. Otherwise,
> > > hopefully one or more of the other bugs here will help, as well as a general
> > > focus on performance that reduces memory/CPU usage in the content process,
> > > which means it's more responsive, which means we get layers sooner, which
> > > means you see the spinners/flashes less often.
> > 
> > Okay then please try out something and post your findings
> > 
> > create a new profile and open 20 tabs with images,
> > or use the session added by OP
> 
> I assume you mean the zipfile on bug 1442573 you added, as the OP here
> didn't add a session? I tried that before posting my earlier comment and saw
> flashes for both cases.

yes & No
sessionstore.jsonlz4 file by u614034

without disabling the animation settings,
closing tabs causes flashes but not spinners,
ctrl+tabs sometimes causes flash.

with cosmetic animation disabled
closing tabs causes flashes always,
ctrl+tabs is instant.

Add tab warming enabled/disabled has no effect.

Comment 37

[Jason Mechelynck]

Attachment: White-black flash after closing tab.webm

Comment 38

[Jason Mechelynck]

Attachment: Flashes-on diff laptop.webm

Comment 39

[Jason Mechelynck]

Attachment: Ctrl+Tab with same pages.webm

Comment 40

[:Gijs (he/him)]

(In reply to Jason Mechelynck from comment #38)
> Created attachment 8995804 [details]
> Flashes-on diff laptop.webm

Some of the flashes here are tab spinners, e.g. freeze the frame at the flash around 0:02, between the image of the hand and that of the light through the trees, there's a spinner at the bottom. Even in the other videos it's possible some of the white/bright flashes are spinners, but the spinner is cut-off at the bottom - there's no obvious way to tell because it's not clear how much of the screen/window is in the screencast.

The other issues (esp. in the other screencasts) with images being replaced with grey rectangles, or just a plain dark/black background without the image, look like gfx/platform issues, but they need a separate bug. You're seeing something else than literally all the other reports here. File a separate bug and needinfo me there. Including the graphics information (from about:support) and RAM information for the machines on which you're seeing this on that bug is likely going to be helpful. It's possible there are cases where we can't keep all the image data in memory or something - but that'll need looking at by some gfx folks.

Comment 41

[Jason Mechelynck]

(In reply to :Gijs (he/him) from comment #40)
> (In reply to Jason Mechelynck from comment #38)
> > Created attachment 8995804 [details]
> > Flashes-on diff laptop.webm
> 
> Some of the flashes here are tab spinners, e.g. freeze the frame at the
> flash around 0:02, between the image of the hand and that of the light
> through the trees, there's a spinner at the bottom. Even in the other videos
> it's possible some of the white/bright flashes are spinners, but the spinner
> is cut-off at the bottom - there's no obvious way to tell because it's not
> clear how much of the screen/window is in the screencast.
> 
> The other issues (esp. in the other screencasts) with images being replaced
> with grey rectangles, or just a plain dark/black background without the
> image, look like gfx/platform issues, but they need a separate bug. You're
> seeing something else than literally all the other reports here. File a
> separate bug and needinfo me there. Including the graphics information (from
> about:support) and RAM information for the machines on which you're seeing
> this on that bug is likely going to be helpful. It's possible there are
> cases where we can't keep all the image data in memory or something - but
> that'll need looking at by some gfx folks.

Thanks for the detailed explanaions in the above comments,
Just one thing so why are the spinners or dark black grey are caused when switching tabs?


Bug 1442573 looks similar? But filed  if similar can you mark if duplicate or something.
posted support info, maybe you guys can fix it soon as you can see how it's breaking the work flow

Comment 42

[Jason Mechelynck]

bug 1479372 filed

Comment 43

[:Gijs (he/him)]

I'll respond in the other bug.

Comment 44

[saproeno]

P1 major bug but is anyone working to fix this?
pita while browsing with this bug.

Comment 45

[:Gijs (he/him)]

I think tab warming (which rode to release in bug 1434651) fixed a lot here. Insofar as there are still issues with tab spinners, they should probably be tracked in bugs with more specific and up-to-date steps to reproduce.