Closed
Bug 1398845
Opened 7 years ago
Closed 6 years ago
Black flash after clicking on site in activity stream
Categories
(Core :: Graphics: Layers, defect, P1)
Tracking
()
People
(Reporter: mstange, Assigned: alexical, NeedInfo)
References
(Blocks 1 open bug)
Details
(Whiteboard: [AS60MVP][gfx-noted][fxperf:p1])
Attachments
(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.
Updated•7 years ago
|
Reporter | ||
Comment 1•7 years ago
|
||
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.
Reporter | ||
Comment 2•7 years ago
|
||
Reporter | ||
Comment 3•7 years ago
|
||
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
Comment 4•7 years ago
|
||
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). STR: 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.
Updated•7 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Iteration: --- → 60.3 - Feb 26
Priority: P3 → P2
Updated•6 years ago
|
status-firefox60:
--- → affected
Updated•6 years ago
|
Whiteboard: [AS60MVP]
Updated•6 years ago
|
Assignee: nobody → andrei.br92
Priority: P2 → P1
Reporter | ||
Comment 7•6 years ago
|
||
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
Updated•6 years ago
|
Assignee: andrei.br92 → nobody
Component: Activity Streams: Newtab → Graphics: Layers
Product: Firefox → Core
Updated•6 years ago
|
Whiteboard: [AS60MVP] → [AS60MVP][gfx-noted]
Assignee | ||
Comment 8•6 years ago
|
||
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: https://searchfox.org/mozilla-central/rev/47cb352984bac15c476dcd75f8360f902673cb98/browser/components/sessionstore/SessionStore.jsm#2965 Figured I'd post that here in case that rings any bells for anyone.
Assignee | ||
Updated•6 years ago
|
Assignee: nobody → dothayer
Status: NEW → ASSIGNED
Comment hidden (mozreview-request) |
Assignee | ||
Comment 10•6 years ago
|
||
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.
Reporter | ||
Comment 11•6 years ago
|
||
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)
Assignee | ||
Comment 12•6 years ago
|
||
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.
Comment hidden (mozreview-request) |
Assignee | ||
Comment 14•6 years ago
|
||
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.
Assignee | ||
Updated•6 years ago
|
Whiteboard: [AS60MVP][gfx-noted] → [AS60MVP][gfx-noted][fxperf:p1]
Reporter | ||
Comment 15•6 years ago
|
||
mozreview-review |
Comment on attachment 8953340 [details] Bug 1398845 - Handle null mBuffer in PaintedLayerComposite::IsOpaque https://reviewboard.mozilla.org/r/222624/#review229312
Attachment #8953340 -
Flags: review?(mstange) → review+
Comment 16•6 years ago
|
||
Pushed by dothayer@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/fcde688c911e Handle null mBuffer in PaintedLayerComposite::IsOpaque r=mstange
Comment 17•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/fcde688c911e
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
Updated•6 years ago
|
Flags: qe-verify+
Comment 19•6 years ago
|
||
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.
Updated•6 years ago
|
Status: RESOLVED → VERIFIED
Updated•6 years ago
|
Flags: qe-verify+
You need to log in
before you can comment on or make changes to this bug.
Description
•