Closed
Bug 751732
Opened 13 years ago
Closed 13 years ago
White/blank screen on Motorola devices
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
RESOLVED
FIXED
mozilla14
People
(Reporter: yury, Unassigned)
References
Details
(Whiteboard: [MTD])
Attachments
(5 files)
(deleted),
application/zip
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
jrmuizel
:
review+
jpr
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
Web page or screen you were on when you saw the issue:
Steps to reproduce (Droid Bionic):
1. Type any URL (even "about:crashes")
2. Nothing is displayed
3. Hit "list of tabs" icon of the tabs
4. Preview images display the page(s) content
What you expected:
Content of the page is visible on step 2
Crash report ID (if applicable):
Comment 1•13 years ago
|
||
Confirmed, using the Droid Bionic from DeviceAnywhere.
This has Android2.3.4 on it.
From gsmarena.com:
http://www.gsmarena.com/motorola_droid_bionic_xt875-3710.php
OS Android OS, v2.3.4 (Gingerbread)
Chipset TI OMAP 4430
CPU Dual-core 1 GHz Cortex-A9
GPU PowerVR SGX540
blocking-fennec1.0: --- → ?
Comment 2•13 years ago
|
||
This is a catlog while loading about:crashes, which turns up white.
Note that loading any website turns up white on that phone, so Fennec is unusable on that phone.
I also crashed twice while starting up (and tapping into the url bar, I think):
https://crash-stats.mozilla.com/report/index/1b48de7e-c4f2-4706-ad8f-e42bf2120504
https://crash-stats.mozilla.com/report/index/7900cbf1-685f-428e-8e11-57ad22120504
bug 737928 NEW crash in js::detail::RegExpCode::compile
Comment 3•13 years ago
|
||
Other phones similar specs; same issues?
* Motorola Atrix 2
* Motorola RAZR XT910
Comment 4•13 years ago
|
||
This might be a regression (from the Maple landing?), we should look and see if we can find a regression range here.
Hopefully the catlog attach has some useful info here.
Keywords: regressionwindow-wanted
Version: Firefox 14 → Trunk
Comment 5•13 years ago
|
||
Some highlights from the log:
05-04 06:09:28.755 D/dalvikvm( 3298): No JNI_OnLoad found in /data/data/org.mozilla.fennec/lib/libmozglue.so 0x4051bc50, skipping init
05-04 06:09:28.857 I/dalvikvm( 3298): Failed resolving Lorg/mozilla/gecko/gfx/SurfaceTextureLayer; interface 105 'Landroid/graphics/SurfaceTexture$OnFrameAvailableListener;'
05-04 06:09:28.857 W/dalvikvm( 3298): Link of class 'Lorg/mozilla/gecko/gfx/SurfaceTextureLayer;' failed
05-04 06:09:28.857 I/dalvikvm( 3298): Could not find method org.mozilla.gecko.gfx.SurfaceTextureLayer.create, referenced from method org.mozilla.gecko.GeckoApp.createSurface
Later, we get:
05-04 06:09:30.380 I/Gecko ( 3273): === SHADER COMPILATION FAILED ===
05-04 06:09:30.404 I/Gecko ( 3273): -- creating basic, not accelerated
At this point, we've failed to create the compositor, and this will indeed cause a blank screen to appear.
Kats, any idea what could be causing the dalvikvm errors above?
In any case, a regression range will be helpful.
Comment 6•13 years ago
|
||
I can confirm that this same issue is present on the Motorola Atrix 2:
Android OS, v2.3 (Gingerbread)
Chipset TI OMAP 4430
CPU Dual-core 1 GHz Cortex-A9
GPU PowerVR SGX540
Updated•13 years ago
|
Summary: White/blank screen → White/blank screen on Motorola devices
Comment 7•13 years ago
|
||
(In reply to Ali Juma [:ajuma] from comment #5)
> 05-04 06:09:28.755 D/dalvikvm( 3298): No JNI_OnLoad found in
> /data/data/org.mozilla.fennec/lib/libmozglue.so 0x4051bc50, skipping init
>
This one is normal I think, I see it often.
> 05-04 06:09:28.857 I/dalvikvm( 3298): Failed resolving
> Lorg/mozilla/gecko/gfx/SurfaceTextureLayer; interface 105
> 'Landroid/graphics/SurfaceTexture$OnFrameAvailableListener;'
> 05-04 06:09:28.857 W/dalvikvm( 3298): Link of class
> 'Lorg/mozilla/gecko/gfx/SurfaceTextureLayer;' failed
> 05-04 06:09:28.857 I/dalvikvm( 3298): Could not find method
> org.mozilla.gecko.gfx.SurfaceTextureLayer.create, referenced from method
> org.mozilla.gecko.GeckoApp.createSurface
It looks like android.graphics.SurfaceTexture is only available on API level >= 11. Adding snorp - I'm not sure if this needs to be in an API level guard or what.
Updated•13 years ago
|
Attachment #621027 -
Attachment mime type: audio/mpeg → application/zip
Comment 8•13 years ago
|
||
(In reply to Kartikaya Gupta (:kats) from comment #7)
> (In reply to Ali Juma [:ajuma] from comment #5)
> > 05-04 06:09:28.755 D/dalvikvm( 3298): No JNI_OnLoad found in
> > /data/data/org.mozilla.fennec/lib/libmozglue.so 0x4051bc50, skipping init
> >
>
> This one is normal I think, I see it often.
>
> > 05-04 06:09:28.857 I/dalvikvm( 3298): Failed resolving
> > Lorg/mozilla/gecko/gfx/SurfaceTextureLayer; interface 105
> > 'Landroid/graphics/SurfaceTexture$OnFrameAvailableListener;'
> > 05-04 06:09:28.857 W/dalvikvm( 3298): Link of class
> > 'Lorg/mozilla/gecko/gfx/SurfaceTextureLayer;' failed
> > 05-04 06:09:28.857 I/dalvikvm( 3298): Could not find method
> > org.mozilla.gecko.gfx.SurfaceTextureLayer.create, referenced from method
> > org.mozilla.gecko.GeckoApp.createSurface
>
> It looks like android.graphics.SurfaceTexture is only available on API level
> >= 11. Adding snorp - I'm not sure if this needs to be in an API level guard
> or what.
That's normal to see when you're on a Gingerbread device. It should be harmless. We don't ever actually call the code in question on that device.
Comment 9•13 years ago
|
||
Looking at the log, I agree with Ali that the shader compilation failure is the likely culprit here.
Comment 10•13 years ago
|
||
Can you give me 'built from' changeset from about:buildconfig? I'm curious to see if on demand shader loading (from bug 716439) is in your build.
Comment 11•13 years ago
|
||
Nevermind, you linked a crash report that had your buildid. That change is not in yet.
Updated•13 years ago
|
Severity: normal → major
Comment 13•13 years ago
|
||
Reproduced over DeviceAnywhere with a
* Motorola Droid 3 (2.3, TI OMAP 4430, PowerVR SGX540)
Updated•13 years ago
|
Assignee: nobody → joe
blocking-fennec1.0: ? → beta+
Comment 14•13 years ago
|
||
It looks like we're failing to create a context - people see problems very much like this when eglCreateWindowSurface fails.
Unfortunately, the Rogers Motorola RAZR doesn't reproduce this problem. Can anyone verify whether the RAZR reproduces it in general?
The failure to compile a) already has all the error messages output and b) is likely only a symptom of the problem.
Comment 15•13 years ago
|
||
What would help us right now is if someone could take a debug Android build and run it with MOZ_GL_DEBUG=1 and MOZ_GL_DEBUG_ABORT_ON_ERROR=1, e.g.
adb shell am start -a android.activity.MAIN -n org.mozilla.fennec_<user>/.App --es env0 MOZ_GL_DEBUG=1 --es env1 MOZ_GL_DEBUG_ABORT_ON_ERROR=1
Comment 16•13 years ago
|
||
Chris, a Droid 3 as per #13 seems to have the problem - we think its available in Europe, can you expense one and see if you can reproduce ASAP?
Comment 17•13 years ago
|
||
Milestone 3 is available in Europe, I think. It seems that no carriers carry it here. :(
Comment 18•13 years ago
|
||
bug 752153 has reported a similar issue, probably the same on the HTC One X (Tegra 3)
Comment 19•13 years ago
|
||
Bug 730890 which is implicated in bug 752153 has not been uplifted to aurora. Has anyone seen this on Aurora?
Aaron, can you bring your Droid 3 to the office tomorrow?
Comment 20•13 years ago
|
||
I tested over DeviceAnywhere services, I don't own one.
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Updated•13 years ago
|
Keywords: regressionwindow-wanted
Comment 22•13 years ago
|
||
Not a duplicate. Using the builds mentioned in comment #11 of bug 752153, I could not reproduce.
I'm a bit confused because the current Nightly (05/07) works on the Atrix II where I initially saw the problem with 05/04.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 23•13 years ago
|
||
Hey Yury,
Would you be able to test current Nightly and see if the problem is resolved? If not, can you try the instructions in comment #11 here? https://bugzilla.mozilla.org/show_bug.cgi?id=752153#c11
Comment 24•13 years ago
|
||
(In reply to Aaron Train [:aaronmt] from comment #23)
> Hey Yury,
>
> Would you be able to test current Nightly and see if the problem is
> resolved? If not, can you try the instructions in comment #11 here?
> https://bugzilla.mozilla.org/show_bug.cgi?id=752153#c11
Based on Yury's response (Bug 752153, Comment 28), it's possible that whatever was causing this bug on May 3rd had been fixed by May 4th.
Reporter | ||
Comment 25•13 years ago
|
||
(In reply to Ali Juma [:ajuma] from comment #24)
> (In reply to Aaron Train [:aaronmt] from comment #23)
> > Hey Yury,
> >
> > Would you be able to test current Nightly and see if the problem is
> > resolved? If not, can you try the instructions in comment #11 here?
> > https://bugzilla.mozilla.org/show_bug.cgi?id=752153#c11
>
> Based on Yury's response (Bug 752153, Comment 28), it's possible that
> whatever was causing this bug on May 3rd had been fixed by May 4th.
Nightly works on the Bionic.
Comment 26•13 years ago
|
||
I have the Motorola droid 3 running android 2.3.4. I've had this problem on nightly for the past ~6 weeks. No webpage will render, it's just a white screen. Also, nightly pretty regularly crashes before loading the white page.
I've been submitting crash reports. Let me know if I can provide any sort of identifier to help track those down to correlate.
Comment 27•13 years ago
|
||
Also reproduced issue on Aurora - droid 3 running android 2.3.4.
Only difference is that is doesn't crash as often as nightly, but same white/blank screen behavior.
Comment 28•13 years ago
|
||
I tested mcoates' Droid 3. Here are my log files.
I could load the Fennec Home and About screens, but I was NOT able to load any web pages. I was able to reproduce the blank page problem once. Every other time I tried to load a page, Fennec crashed.
The logs report some suspicious error messages about dalvikvm failing to load org.mozilla.gecko.gfx.SurfaceTextureLayer:
D ActivityRenderTarget: onPause
W dalvikvm: Link of class 'Lorg/mozilla/gecko/gfx/SurfaceTextureLayer;' failed
W dalvikvm: VFY: unable to resolve static method 7598: Lorg/mozilla/gecko/gfx/SurfaceTextureLayer;.create ()Lorg/mozilla/gecko/gfx/SurfaceTextureLayer;
W dalvikvm: VFY: unable to resolve virtual method 71: Landroid/app/DownloadManager;.addCompletedDownload (Ljava/lang/String;Ljava/lang/String;ZLjava/lang/String;Ljava/lang/String;JZ)J
W dalvikvm: Link of class 'Lorg/mozilla/gecko/gfx/SurfaceTextureLayer;' failed
E dalvikvm: Could not find class 'org.mozilla.gecko.gfx.SurfaceTextureLayer', referenced from method org.mozilla.gecko.GeckoApp.showSurface
05-07 15:23:36.052 24821 24821 W dalvikvm: VFY: unable to resolve check-cast 1435 (Lorg/mozilla/gecko/gfx/SurfaceTextureLayer;) in Lorg/mozilla/gecko/GeckoApp;
Comment 29•13 years ago
|
||
Comment 30•13 years ago
|
||
joedrew, I tested your try build e5f988326565 on mcoates' Droid 3. I was successfully able to view web pages! Do you want my logcat logs from that test run?
Comment 31•13 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=e5f988326565 for a fast link
Comment 33•13 years ago
|
||
Mary Colvig has a Droid 3 too (duplicate bug 752708).
Comment 34•13 years ago
|
||
for me, this build is broken as the reporter describes:
https://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2012-05-04-03-05-09-mozilla-central-android/fennec-15.0a1.en-US.android-arm.apk
and this build works fine
https://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2012-05-05-03-05-10-mozilla-central-android/fennec-15.0a1.en-US.android-arm.apk
Comment 35•13 years ago
|
||
those two builds have this range https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2db9df42823d&tochange=0a48e6561534
Comment 36•13 years ago
|
||
Given Brad and Yury's comments, this was fixed 'by accident' somehow. I'm going to bisect tomorrow to see how it got fixed.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → WORKSFORME
Comment 37•13 years ago
|
||
bisect results:
Due to skipped revisions, the first good revision could be any of:
changeset: 93046:10cd5a5210f2
parent: 93045:d32d6823f0af
parent: 92905:cc91f155491b
user: Ehsan Akhgari <ehsan@mozilla.com>
date: Thu May 03 17:33:52 2012 -0400
summary: Merge from mozilla-central
changeset: 93047:43b2b050af51
user: Bas Schouten <bschouten@mozilla.com>
date: Thu May 03 23:41:37 2012 +0200
summary: Bug 738413 - Followup: Move ToIntRect to a Rect class method. r=roc
changeset: 93048:26738df8a4e0
user: Matt Brubeck <mbrubeck@mozilla.com>
date: Thu May 03 14:55:52 2012 -0700
summary: Back out 682bf201edde, ef35ba222ac8, and 6a20cf61289d (bug 750907, bug 751003, bug 751377) because of build failure on a CLOSED TREE
that merge has:
eakhgari@mozilla.com
Thu May 03 14:33:59 2012 -0700 10cd5a5210f2 Ehsan Akhgari — Merge from mozilla-central
← 4 hidden changesets [Collapse]
cc91f155491b Ehsan Akhgari — Bug 751611 - Add mozconfig files for building Win32 binaries on our Win64 bit platforms; r=khuey DONTBUILD
2db9df42823d Gregory Szorc — Bug 749957; r=rnewman
c045085c0436 Brian R. Bondy — Bug 670514 - LNK file test for Windows share security. r=bz
60613f18435b Brian R. Bondy — Bug 670514 - Arbitrary File + Directory read via .lnk files on Windows Share. r=bz
no clear winner there
Comment 38•13 years ago
|
||
I'm assuming this is still a problem on Aurora. Is this correct? If so, we still need to figure out what fixed it so we can make sure it gets backported.
Reporter | ||
Comment 40•13 years ago
|
||
(In reply to Matt Brubeck (:mbrubeck) from comment #38)
> I'm assuming this is still a problem on Aurora. Is this correct?
That's correct. (Double verified with http://mzl.la/mtd-aurora)
Comment 41•13 years ago
|
||
Reopening until this is settled.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 42•13 years ago
|
||
I'm in the process of an hg bisect --extend (which includes the contents of merges). Once I figure out which patch we need to uplift, I'll mark it as such.
Comment 43•13 years ago
|
||
changeset: 92942:77bf50b33a05
user: Nicholas Cameron <ncameron@mozilla.com>
date: Wed May 02 14:54:40 2012 +1200
summary: Bug 716439; compile OGL shaders lazily. r=BenWa
Depends on: GPU-clipping-rounded
Comment 44•13 years ago
|
||
Nick's patch needed to be more-or-less rewritten to apply to Aurora, and even still it doesn't fix this bug. I'm now going to try uplifting all of bug 716439.
Comment 45•13 years ago
|
||
Uplifting all of bug 716439 (and its dependent bug 733894) fixes this problem, but actually doing that uplift and shipping it to our users is crazypants.
Still, I pushed this patch queue on top of aurora to try: https://tbpl.mozilla.org/?tree=Try&rev=354e84cfc357
(In reply to Joe Drew (:JOEDREW!) from comment #45)
> Uplifting all of bug 716439 (and its dependent bug 733894) fixes this
> problem, but actually doing that uplift and shipping it to our users is
> crazypants.
You could try working your way through the patch queue to see which one of Nick's patches actually fixed this; that might give us useful information.
Comment 47•13 years ago
|
||
We don't know why, but these shaders don't compile on Motorola devices. Since we don't use component alpha on GLES, just disable their content there.
Attachment #622530 -
Flags: review?(jmuizelaar)
Attachment #622530 -
Flags: approval-mozilla-aurora?
Comment 48•13 years ago
|
||
Comment on attachment 622530 [details] [diff] [review]
disable component alpha shaders
Splendid.
Attachment #622530 -
Flags: review?(jmuizelaar) → review+
Comment 49•13 years ago
|
||
Comment on attachment 622530 [details] [diff] [review]
disable component alpha shaders
Approved, should be mobile only.
Attachment #622530 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Seems like we should get some kind of usable and easily diagnosable feedback if our shaders fail to compile!
Comment 51•13 years ago
|
||
Assignee: joe → nobody
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Component: General → Graphics: Layers
Product: Fennec Native → Core
QA Contact: general → graphics-layers
Resolution: --- → FIXED
Target Milestone: Firefox 15 → mozilla14
Comment 52•13 years ago
|
||
I have a similar issue to this one on my Motorola Photon that is still happening with http://ftp.mozilla.org/pub/mozilla.org/mobile/candidates/14.0b1-candidates/build3/unsigned/android/en-US/ which is the latest beta. In my case the pages load black instead of white. I can reproduce it just by loading about:crashes
Android 2.3.4
I can file another bug if it doesn't belong here but when I mentioned it the other day I was directed to this bug and I believe they said it would be fixed in the latest beta.
Comment 53•13 years ago
|
||
(In reply to Marcia Knous [:marcia] from comment #52)
> I have a similar issue to this one on my Motorola Photon that is still
> happening with
> http://ftp.mozilla.org/pub/mozilla.org/mobile/candidates/14.0b1-candidates/
> build3/unsigned/android/en-US/ which is the latest beta. In my case the
> pages load black instead of white. I can reproduce it just by loading
> about:crashes
>
> Android 2.3.4
>
> I can file another bug if it doesn't belong here but when I mentioned it the
> other day I was directed to this bug and I believe they said it would be
> fixed in the latest beta.
marcia, Joe confirmed this is bug 751732. I'll move your comments over there and we can track discussion in that bug. thanks for the report!
Comment 54•13 years ago
|
||
(In reply to Tony Chung [:tchung] from comment #53)
> marcia, Joe confirmed this is bug 751732.
Correction, reference bug is bug 754253.
Comment 55•13 years ago
|
||
FYI - The Firefox beta worked perfectly on my droid 3 (which previously has had the white-blank screen issue in this bug).
However, after we released the first beta update (the next day I think) the white-blank screen issue returned.
Comment 56•13 years ago
|
||
Also, is this bug supposed to be marked resolved? I'm happy to verify in nightly if that's where the fix is. Please let me know.
Comment 57•12 years ago
|
||
(In reply to Michael Coates [:mcoates] from comment #56)
> Also, is this bug supposed to be marked resolved? I'm happy to verify in
> nightly if that's where the fix is. Please let me know.
Is this still a problem Michael? If so, please re-open the bug.
You need to log in
before you can comment on or make changes to this bug.
Description
•