Closed Bug 1030523 Opened 6 years ago Closed 6 years ago

Content view sometimes blank on load

Categories

(Firefox for Android :: Toolbar, defect)

31 Branch
ARM
Android
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 36
Tracking Status
firefox34 --- wontfix
firefox35 + fixed
firefox36 + fixed
fennec + ---

People

(Reporter: jwir3, Assigned: kats)

References

Details

Attachments

(4 files)

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.
Attached image Tabs view
Attached image Blank content
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).
Hardware: Other → x86
Version: unspecified → Firefox 31
Hardware: x86 → ARM
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.
Keywords: steps-wanted
tracking-fennec: --- → ?
Assignee: nobody → snorp
tracking-fennec: ? → 33+
tracking-fennec: 33+ → 34+
tracking-fennec: 34+ → +
Duplicate of this bug: 1078340
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.
Attachment #8501019 - Flags: review?(snorp)
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.
Attachment #8501019 - Flags: review?(snorp) → review+
https://hg.mozilla.org/mozilla-central/rev/7246195fb751
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 36
See Also: → 1085405
[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
Attachment #8501019 - Flags: approval-mozilla-beta?
Attachment #8501019 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Occurs for me in Firefox 68, Android 8.0.0, Moto G6 (as of July through August 2019)

You need to log in before you can comment on or make changes to this bug.