Closed Bug 1151102 Opened 5 years ago Closed 4 years ago

Page loads, entire viewport is blank

Categories

(Firefox for Android :: Toolbar, defect)

All
Android
defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 48
Tracking Status
firefox40 --- affected
firefox48 --- fixed

People

(Reporter: rnewman, Assigned: kats)

Details

Attachments

(3 files)

Attached file blankpage2.log
Reader mode icon shows, logs indicate that the page content has loaded. Content view entirely blank.

Nightly 40. This has been a topic of user feedback for ages, and I don't see a bug on it.

I have logcats for multiple reloads of the same failing page.

Once Fennec gets into this state, other pages -- even those it already loaded, e.g., m.wikipedia -- are also all white.

The logs are very boring, but here they are.

This is with VERBOSE set to all the graphics log tags I could find.
Bug 1129074 generally covers this but there might be multiple causes.
Attachment #8588186 - Attachment mime type: text/x-log → text/plain
Attachment #8588187 - Attachment mime type: text/x-log → text/plain
Bug 1158309 is the one with a fix for related stuff, and is on 40 beta, it's worth checking if this is still around.
Richard, do you still see this?
Flags: needinfo?(rnewman)
I'm full-time on iOS right now, so I'm afraid I can neither confirm nor deny.
Flags: needinfo?(rnewman)
SEEMS to be reproducible in Nightly on a really recent CM12.1 nightly on my OPO, if that helps.
The next time somebody runs into this problem, please try long-pressing on the page and see if you get the text selection handles. If you can drag around the text selection handles and they seem to be positioned where they should be if the page was visible, then it's quite likely that the page is actually rendered but we just never got the first-paint notification in Java and never cleared the background on the LayerView. If this is the case we can try to figure out why, or we can add a fallback path somewhere.
The handles do indeed appear to move around as if the page was visible.
Thsnks.

I looked around in the code a bit but couldn't spot any obvious places where the first-paint notification would get dropped. I've put together a patch for additional logging so if you anybody else runs into this problem again the log should provide more info.
Attachment #8658799 - Flags: review?(snorp) → review+
I started hitting that on b2gdroid at every first start of the homescreen recently. It only gets painted after another app is launched.
I'm using a Nexus 4 running CM 12.1 I don't get text selection handles.

I got these logs:

I/GeckoBug1151102(29897): Initialized surfaceview
I/GeckoBug1151102(29897): Reseting layer client: 0
I/GeckoBug1151102(29897): PresShell doing a first-paint
I/GeckoBug1151102(29897): Done first paint; state 0
I/GeckoBug1151102(29897): Cleared bg color

I/GeckoBug1151102(30004): PresShell doing a first-paint

PID 29897 is the parent process, running the system app. PID 30004 is the Homescreen.
Hmm the output you're getting indicates it's some other problem. But since it's B2G droid (which apparently is multiprocess, I didn't know that) it may not be the same problem as what this bug was originally filed for.
Ok. Kats, do you want me to file a new bug? Any idea what I should look at before bisecting?
Flags: needinfo?(bugmail.mozilla)
Ok, I found a fix for b2gdroid.
Flags: needinfo?(bugmail.mozilla)
Whiteboard: [waiting for logcat from somebody who can reproduce]
Haven't heard a peep on this in over 6 months, so I'm going to assume nobody is seeing it. I'll back out the logging patch and close as WFM.
Assignee: nobody → bugmail.mozilla
Keywords: leave-open
Whiteboard: [waiting for logcat from somebody who can reproduce]
https://hg.mozilla.org/mozilla-central/rev/0ff845d0898e
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
Got this on latest download of Firefox 48.0 Linux mint.

Firefox was running in a separate virtual screen. Was operating in a different screen and the return to Firefox's VS showed a blank FF viewport, although the page and clickable elements were still there, and could be revealed by activating any element that redrew (part of) the screen. 

Sorry didn't recall exactly what was happening elsewhere, or take screenshot.

If its relevant Nvidia video HW running Nvidia-5352 driver.
(In reply to tnp from comment #20)
> Got this on latest download of Firefox 48.0 Linux mint.

If you can reproduce this, please file a new bug. It's likely a separate issue, possibly related to the virtual screen. This bug was about an Android issue and the codepaths used there are quite different than on Linux.
May very well be bug 1292613, so check that before filing a new one?
You need to log in before you can comment on or make changes to this bug.