1298822 - Restoring Fennec paints black screen

Status: RESOLVED FIXED

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

Description

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 1

[Marcia Knous [:marcia]]

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.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 3

[(inactive) Jim Chen [:jchen] [:darchons]]

I'd say bug 1296757, but I'll check.

Comment 4

[(inactive) Jim Chen [:jchen] [:darchons]]

I can't reproduce this on my Nexus 4 running 4.4.3 and 8-30 nightly. Anything in the logcat?

Comment 5

[Kartikaya Gupta (email:[e-mail])]

Attachment: 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.

Comment 6

[(inactive) Jim Chen [:jchen] [:darchons]]

Attachment: Invalidate before resuming compositor (v1)

Invalidate before resuming the compositor to make sure we actually
perform a render on resume.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

^ patch fixes it for me on a local build. thanks!

Comment 8

[James Willcox (:snorp) ([e-mail]) (he/him)]

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

Comment 9

[James Willcox (:snorp) ([e-mail]) (he/him)]

I tried the above and it also fixes it for me. I'm curious why this would just now be showing up, though.

Comment 10

[James Willcox (:snorp) ([e-mail]) (he/him)]

Attachment: Always invalidate layers when resuming the compositor

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/dec6a438ea43
Always invalidate layers when resuming the compositor r=BenWa

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/dec6a438ea43

Comment 13

[Sorina Florean [:sflorean]]

Verified as fixed on Firefox 51 Beta 7.
Device: Asus ZenPad 8 (Android 6.0.1).