STR: 1. Open a new tab (doesn't happen consistently). Expected results: Page loads, content is displayed Actual Results: Page shows loading bar, favicon comes up, but content area is blank ( see screenshot). This only happens to me when I am navigating to a URL from an outside source (e.g. Google search or a link from my email). I can see that the content is loaded because on the tabs view, it renders.

Also, any content I view from this point on (e.g. loading a new tab or selecting an existing tab) has the same blank content.

This is on a nexus 5 with stock KitKat (rooted).

I saw some chatter on IRC about this as well, but haven't seen it happen myself. Would like STR so I can repro and debug.

I haven't yet run into this in Fennec, but I have seen it in a webapp that I have that runs on aurora. If I start the webapp, then immediately hit the home button to put the webapp in the background (while it is still on the splash screen), and then later bring it back to the foreground, it doesn't render anything and just stays blank the whole time. I suspect this is the same issue - somewhere during startup the GL context is not available and we get stuck in a bad state or something like that.

I grabbed a log using the STR I described above (with which I can reliably reproduce the problem). There is a stacktrace in the log that indicates the allocation of the GL surface is failing, as I surmised. The code is supposed to be able to handle this scenario, by calling updateCompositor() again fennec becomes visible again. A quick glance through the code shows that the change at https://hg.mozilla.org/mozilla-central/rev/038356d89dc2 may have broken this, because surfaceChanged(...) is not called any more when onSizeChanged is invoked and the compositor isn't created yet. That seems like a bug, and I"m pretty sure that patch isn't doing what it was intended to be doing, because the surfaceChanged(...) call does more or less the same thing as the bottom of onSizeChanged, and it doesn't make sense to do both. I'm spinning up a local build with some extra logging to confirm my theory.

I confirmed my theory with logging and backing out that change improves the situation considerably. With my patch the compositor starts up properly but the screen remains blank initially. Using the app switcher to re-select the webapp makes it render normally again.

This helps quite a bit with the STR I was able to repro, although it doesn't fix it entirely as mentioned above. I'm not sure what I need to do to get it to repaint right away.

I think I can reproduce this consistently when I try to load shoppersdrugmart.ca. It loads an empty page in Firefox 32, 33, and 35 but loads fine in Chrome on my Nexus 5 and Asus Transformer tablet.

I think that's a different issue. This bug is about Firefox rendering *all* pages as blank, while the tab tray shows that the pages definitely have content. shoppersdrugmart.ca is showing up blank for me as well, but it doesn't get Firefox stuck in a bad state. That's worth filing a separate bug about though.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #11) > That's worth filing a separate bug about though. Filed bug 1080743, thanks kats.

Comment on attachment 8501019 [details] [diff] [review] Backout of earlier cset Review of attachment 8501019 [details] [diff] [review]: ----------------------------------------------------------------- Still not sure I fully understand what is going on here, but if this makes things better then I'm happy. I'd like to talk about this some more this week to see if we can get the last issue figured out.

[Tracking Requested - why for this release]: resolves a known issue

Comment on attachment 8501019 [details] [diff] [review] Backout of earlier cset Approval Request Comment [Feature/regressing bug #]: bug 834243 [User impact if declined]: sometimes the content view ends up blank in fennec, which is very annoying. once in this state you pretty much have to restart fennec to fix it [Describe test coverage new/current, TBPL]: on m-c for a while now [Risks and why]: affects android only. the code being modified is obviously wrong so I would say there's a low risk that this will make things worse [String/UUID change made/needed]: none

Already fixed.