Closed Bug 1298822 Opened 5 years ago Closed 5 years ago
Restoring Fennec paints black screen
This is 100% reproducible for me on Nightly on my Nexus 4. I load a page (my bugmail dashboard, for example) and hit the home button to go back to the home screen. Then I switch back into Fennec either by tapping on the homescreen icon or using the app switcher - Fennec loads but the content area is entirely black. Tapping on the content area or opening the tabswitcher causes it to repaint properly. Not sure if maybe we're just not recompositing or what. It's a really bad UX, so requesting tracking/blocker for 51. I'll bisect this down later today. I didn't see it happening on my Z3C so maybe it's racy or device-specific.
5 years ago
Tracking 51+ for now so we can investigate this issue and not lose track of it as it seems to be a poor user experience.
mozregression narrowed it down to this: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7cae917bd51939b9f642dd8bcb16e081ae721a6a&tochange=ca1fbb8218da27833878ac481b194b7ddf865a67 One of Jim's changes is the culprit, not sure which one.
I'd say bug 1296757, but I'll check.
I can't reproduce this on my Nexus 4 running 4.4.3 and 8-30 nightly. Anything in the logcat?
Not really. Attached the log - this starts off with Fennec in the foreground, then I hit the home button to put it in the background, and then I tap on the homescreen icon to bring it back into the foreground (and the screen is black at this point). This is on a local build, so if you want me to add any specific logging feel free to send me a patch and I can apply it and repro with that.
tracking-fennec: --- → ?
tracking-fennec: ? → 51+
Invalidate before resuming the compositor to make sure we actually perform a render on resume.
Attachment #8786912 - Flags: review?(snorp)
^ patch fixes it for me on a local build. thanks!
Comment on attachment 8786912 [details] [diff] [review] Invalidate before resuming compositor (v1) I think the nature of resuming demands that this should occur in the Compositor machinery itself. Just call Invalidate() in CompositorBridgeParent::ResumeComposition() But a gfx person should probably review that change
Attachment #8786912 - Flags: review?(snorp) → review-
I tried the above and it also fixes it for me. I'm curious why this would just now be showing up, though.
Attachment #8786927 - Flags: review?(bgirard)
Assignee: nchen → snorp
Attachment #8786927 - Flags: review?(bgirard) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/dec6a438ea43 Always invalidate layers when resuming the compositor r=BenWa
Verified as fixed on Firefox 51 Beta 7. Device: Asus ZenPad 8 (Android 6.0.1).
You need to log in before you can comment on or make changes to this bug.