Closed Bug 1298822 Opened 5 years ago Closed 5 years ago

Restoring Fennec paints black screen

Categories

(Firefox for Android Graveyard :: Toolbar, defect, P1)

51 Branch
All
Android
defect

Tracking

(firefox49 unaffected, fennec51+, firefox50 unaffected, firefox51+ verified)

RESOLVED FIXED
Firefox 51
Tracking Status
firefox49 --- unaffected
fennec 51+ ---
firefox50 --- unaffected
firefox51 + verified

People

(Reporter: kats, Assigned: snorp)

Details

(Keywords: regression)

Attachments

(3 files)

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.
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.
I'd say bug 1296757, but I'll check.
Flags: needinfo?(nchen)
Assignee: nobody → nchen
I can't reproduce this on my Nexus 4 running 4.4.3 and 8-30 nightly. Anything in the logcat?
Flags: needinfo?(bugmail)
Attached file 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.
Flags: needinfo?(bugmail)
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.
Assignee: nchen → snorp
Attachment #8786927 - Flags: review?(bgirard) → review+
Pushed by jwillcox@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/dec6a438ea43
Always invalidate layers when resuming the compositor r=BenWa
https://hg.mozilla.org/mozilla-central/rev/dec6a438ea43
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 51
Verified as fixed on Firefox 51 Beta 7.
Device: Asus ZenPad 8 (Android 6.0.1).
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.