Closed Bug 1398845 Opened 3 years ago Closed 3 years ago

Black flash after clicking on site in activity stream


(Core :: Graphics: Layers, defect, P1)




60.3 - Feb 26
Tracking Status
firefox57 --- wontfix
firefox58 --- wontfix
firefox60 --- verified


(Reporter: mstange, Assigned: dthayer, NeedInfo)


(Blocks 1 open bug)


(Whiteboard: [AS60MVP][gfx-noted][fxperf:p1])


(3 files)

Steps to reproduce:
 1. Open a new tab.
 2. Click one of the Top Sites.

After the click, the window briefly flashes black before it becomes white and starts loading the page.

I think this indicates that the compositor doesn't have any content for the content area.
Attached video screen recording
This doesn't happen all the time, but it happens some of the time. The flash sometimes isn't completely black but instead has a white background with black strips on the sides of the window.
My guess would be that this happens because we're switching frame loaders during the navigation (bug 1376895).

Strangely, I do not see a flash if I navigate from a moz-extension:// URL to a https:// URL.
I also do not see a flash when clicking a link on a file:// URL to navigate to a https:// URL, but in that case we seem to be re-using the file content process in order to load web content.
Blocks: 1376895
I'm seeing this same issue in 57.0b7 also using Twitter as an example. I do see the whole screen flash but have seen the "black strips" version of this issue that Markus mentions. I'm on a Retina 5K, 27-inch, Late 2015 with an AMD Radeon R9 M395 graphics card (in case that's somehow meaningful).


1. Open Firefox on Mac OS X (Sierra & High Sierra have both done this for me).
2. With a single window open and one new tab open click on a site that has a white background (for most obvious effect).
3. See screen flash black quickly between new tab and the web page.
Iteration: --- → 60.3 - Feb 26
Priority: P3 → P2
Whiteboard: [AS60MVP]
Is this still happening?
Flags: needinfo?(mstange)
Yes it is.
Flags: needinfo?(mstange)
Assignee: nobody → andrei.br92
Priority: P2 → P1
Blocks: 1437659
This is probably a bug in Firefox graphics code (somewhere around LayerManagerComposite), not in Activity Stream itself.

mconley has been looking into similar issues recently but has put that investigation on hold; here's what he thinks:

<mconley> mstange: I _think_ it's a compositor problem. The compositor isn't dealing with the case where we switch processes in nsFrameLoader from the preloaded newtab process to a new or pre-existing content process
Assignee: andrei.br92 → nobody
Component: Activity Streams: Newtab → Graphics: Layers
Product: Firefox → Core
Whiteboard: [AS60MVP] → [AS60MVP][gfx-noted]
Been looking into this a little bit - strangely I can reliably produce this unless I remove the line where we set the tab to busy:

Figured I'd post that here in case that rings any bells for anyone.
Assignee: nobody → dothayer
Update: the above patch fixes the problem, and it seems to be a legitimate bug since a PaintedLayerComposite's region should not be considered opaque if its mBuffer is null, since it won't contribute anything to be rendered, but I still need to keep looking at this to understand why we're getting into this state and if that should be considered a bug or not.
So it sounds like we're removing the ContentHost for a PaintedLayer of a layer tree (maybe through layerManager->ClearCachedResources(), maybe through something else) while there is still a RefLayer in the parent process that refers to this layer tree. Matt, do you know if that is supposed to happen, or if not, what is supposed to prevent it?
Flags: needinfo?(matt.woodrow)
It's through ClearCachedResources()

The abridged chain of events is (as far as I can tell debugging).

browser.js RedirectLoad() ... tabbrowser.xml parent.removeChild(browser)
-> TabChildParent::Destroy() ... SendClearCachedResources()

But we only get into this state if we quickly run "parent.appendChild(browser)" after the removeChild, if that makes any sense.
Requestion review from you Markus since regardless of the verdict on whether this is supposed to happen, I'd like to land the fix now while there's still a little time left in the cycle. If you think we should wait though I'm fine with that.
Whiteboard: [AS60MVP][gfx-noted] → [AS60MVP][gfx-noted][fxperf:p1]
Comment on attachment 8953340 [details]
Bug 1398845 - Handle null mBuffer in PaintedLayerComposite::IsOpaque
Attachment #8953340 - Flags: review?(mstange) → review+
Pushed by
Handle null mBuffer in PaintedLayerComposite::IsOpaque r=mstange
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
Duplicate of this bug: 1441717
I was able to reproduce the issue on Mac OS X 10.13, using Fx 57.0a1.
Tested on Fx60.0b11 and latest Fx61.0a1. I can confirm the issue no longer occurs.
You need to log in before you can comment on or make changes to this bug.