1151102 - Page loads, entire viewport is blank

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[Richard Newman [:rnewman]]

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

Comment 1

[Richard Newman [:rnewman]]

Attachment: Earlier log, multiple tries

Comment 2

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

Bug 1129074 generally covers this but there might be multiple causes.

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

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.

Comment 4

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Richard, do you still see this?

Comment 5

[Richard Newman [:rnewman]]

I'm full-time on iOS right now, so I'm afraid I can neither confirm nor deny.

Comment 6

[The0x539]

SEEMS to be reproducible in Nightly on a really recent CM12.1 nightly on my OPO, if that helps.

Comment 7

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

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.

Comment 8

[The0x539]

The handles do indeed appear to move around as if the page was visible.

Comment 9

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

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.

Comment 10

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

Attachment: Logging patch

Comment 11

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f98e6bf59631

Comment 12

[Carsten Book [:Tomcat]]

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

Comment 13

[[:fabrice] Fabrice Desré]

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.

Comment 14

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

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.

Comment 15

[[:fabrice] Fabrice Desré]

Ok. Kats, do you want me to file a new bug? Any idea what I should look at before bisecting?

Comment 16

[[:fabrice] Fabrice Desré]

Ok, I found a fix for b2gdroid.

Comment 17

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

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.

Comment 18

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0ff845d0898e

Comment 19

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/0ff845d0898e

Comment 20

[tnp]

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.

Comment 21

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

(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.

Comment 22

[Milan Sreckovic [:milan] (needinfo for best results)]

May very well be bug 1292613, so check that before filing a new one?