Closed Bug 754257 Opened 12 years ago Closed 12 years ago

Firefox won´t open new pages, content area is white

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set
major

Tracking

(firefox14 affected, firefox15 affected, blocking-fennec1.0 +)

VERIFIED DUPLICATE of bug 760226
Tracking Status
firefox14 --- affected
firefox15 --- affected
blocking-fennec1.0 --- +

People

(Reporter: jan.manthay, Assigned: jrmuizel)

References

Details

(Whiteboard: [gfx])

Attachments

(4 files)

After opening Nightly 15 the content area is white, and no pages load. The interface works, so I can open new sites through bookmarks, but nothing happens.

Log is attached
Attached file logfile
Device? Nightly build? Android OS?
Status: UNCONFIRMED → NEW
Ever confirmed: true
blocking-fennec1.0: --- → ?
Need more details and STR
Keywords: qawanted
I was unable to reproduce the issue on HTC Desire Z(Android 2.3.3) and HTC Desire (Android 2.2) in several attempts using Nightly 15.0a1 2012-05-13. I have tried recovering from OOM device soft restart, crash recovery start/maximize app in landscape. From the logs the device seems to be a sonyericsson but I do not have access to any sonyericsson device to further test this. Logs indicate https://addons.mozilla.org/en-US/android/, http://www.camp-firefox.de/forum/ and http://www.heise.de/ as the links visited.
Attached image A nonhelpful screenshot
I did reproduce on the samsung galaxy S II

Once I got into this state, none of new content will show until I quit and start again.  This is on 5/14/2012; after updating and also going to about:firefox after sleep.
Device was an Sony Xperia Mini with Android 2.3.4.
Build was from the day of the bug report.
All sites are effected.
It looks like on the screenshot from Naoki Hirata.


I had a simmilar bug in Aurora, only in black:
https://bugzilla.mozilla.org/show_bug.cgi?id=754253
Status: NEW → RESOLVED
blocking-fennec1.0: ? → +
Closed: 12 years ago
Resolution: --- → DUPLICATE
I was able to create the white page issue:
1. on a LG revolution, launch Nightly
2. hit the home button
3. launch Aurora, try to go to about:firefox
Will either crash or get a white screen; restart aurora
4. open Nightly, type "about:" in the awesome bar and then tap on the about:firefox

Expected: no white screen
Actual: white screen
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Note: I got the white screen on both aurora and nightly from 5/18
Attached file logcat
Not sure but it may have something to do with having two Firefox open and a HDMI mirror capability on the phone?
Assignee: nobody → bgirard
Can't reproduce with the HTC desire. Got 2 fennec beta/custom running. Switching between the two is working fine. They don't even get evicted with both running cnn.com
I get the problem on the Nexus One, the oldest Adreno device we have on hand. Looking into it.
I don't know if this is a different problem, I see the same symptoms when I compile my local build with the mozconfig flag:

  ac_add_options --disable-install-strip

Presumably the non-stripped binary triggers OOM sooner?
OOM should crash the app, not prevent rendering.
Severity: normal → major
When trying to reproduce this crash I often run into a crash while starting up the second instance:
###!!! ABORT: OOM: file /home/bgirard/mozilla/kiwifox/tree/xpcom/string/src/nsTSubstring.cpp, line 291
(In reply to Benoit Girard (:BenWa) from comment #12)
> Can't reproduce with the HTC desire. Got 2 fennec beta/custom running.
> Switching between the two is working fine. They don't even get evicted with
> both running cnn.com

I can reliably reproduce with HTC Desire (Android 2.2). Only Firefox instance installed on phone is Firefox Beta.
Whiteboard: [gfx]
I saw the phone was failing to create the EGLConfig. It reports that none are available. Rebooting the phone fixes the problem. We could detect that case and show an error message to the user perhaps.
Alright I did further investigating. This issue is caused by us not being able to create a GL context. This boils down to not being able to create an EGLConfig. I've seen this degrade into crashing on startup trying to bring up the GL context. Once we enter this bad state it appears that Android doesn't allow any app to use OpenGL. I've seen Quantrand Standard also crash on start up.

I suspect this could be linked to not releasing OpenGL view when we crash.

Is it possible for QA to give me a hand with finding minimal steps to reproduce to get into this bad state. Once we understand what is causing us the enter this bad state we investigate if we can into this state without using Fennec. If so we might have to provide an error splash screen when we see we can't create a GLContext.
Keywords: qawanted
(In reply to Benoit Girard (:BenWa) from comment #21)

> Once we enter this bad state it appears that Android
> doesn't allow any app to use OpenGL. I've seen Quantrand Standard also crash
> on start up.

This whould explain this bug I reportet the same day:
Bug 754238
Jeff is going to own this bug, I have to many blockers ATM.
Assignee: bgirard → jmuizelaar
We should be able to help this by swapping the order of context creation so that we create the global one afterwards and if it fails we can still draw.
Depends on: 760226
Blocks: 759866
I can see this still happening on xperia mini pro(android 2.3) as well as HTC desire with newest nightly and aurora builds.
No longer blocks: 759866
Depends on: 759866
Now, that bug 759866 has landed we should crash instead of showing white. It would be good to know if anyone is still seeing white starting with tomorrow's nightly.
Also, once bug 760226 merges into m-c and bjacobs plan to remove the global EGL is complete I'm hoping this bug will be fixed.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #27)
> Also, once bug 760226 merges into m-c and bjacobs plan to remove the global
> EGL is complete I'm hoping this bug will be fixed.

All of the known fixes have now been merged into m-c. I'd like to know if anyone can still reproduce this on a current m-c build.
Marking as fixed. Please reopen if anyone can still reproduce the problem.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Making this a dupe to make tracking easier.
Resolution: FIXED → DUPLICATE
Removing QA wanted.  Seems fixed

HTC Desire HD Nightly/Aurora 6/5/2012
Status: RESOLVED → VERIFIED
Keywords: qawanted
(In reply to Naoki Hirata :nhirata from comment #31)
> Removing QA wanted.  Seems fixed
> 
> HTC Desire HD Nightly/Aurora 6/5/2012

Could you reproduce the problem on a HTC Desire HD before? That seems too new to me and isn't mentioned in the bug.
Status: VERIFIED → RESOLVED
Closed: 12 years ago12 years ago
Keywords: qawanted
yes, I did reproduce on the HTC Desire HD.

Note: I notice this issue on a different device (Nexus S) only after I installed the latest dev version of Ad Block: https://adblockplus.org/devbuilds/adblockplus/

I get a feeling that the secondary is different and should be logged as a separate bug.
Meh.  I should have reread before hitting return for my comment.

To clarify:
Yes, I did reproduce the issue prior to this bug being closed.
I cannot reproduce this issue with the Nightly tested when I had closed the bug as verified.

I will be opening a new bug in regards to the ad block plus soon.  ( I want to do some further testing before opening the bug )
Status: RESOLVED → VERIFIED
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: