Closed
Bug 578952
Opened 14 years ago
Closed 14 years ago
Page doesn't load when electrolysis is enabled
Categories
(Toolkit :: Crash Reporting, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
fennec | 2.0a1+ | --- |
People
(Reporter: proppy, Assigned: cjones)
References
(Depends on 1 open bug, )
Details
Attachments
(1 file)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.6) Gecko/20100628 Ubuntu/10.04 (lucid) Firefox/3.6.6
Build Identifier: Mozilla/5.0 (X11; Linux armv7l; fr; rv:2.0b2pre) Gecko/20100715 Namoroka/4.0b2pre Fennec/2.0a1pre
Page doesn't load when browser.tabs.remote is true.
Page load when browser.tabs.remote is false
Reproducible: Always
Steps to Reproduce:
1. Install After installing http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mobile-trunk-maemo5-gtk/fennec_2.0~a1~20100715010459_armel.deb
2. Type google.com in the address bar
3. Hit enter
Actual Results:
It shows a checker board
Expected Results:
It should show google.com
If settings browser.tabs.remote to 'false' in about:config, the page does load.
Comment 1•14 years ago
|
||
I found this same problem with a local build of Fennec. I "fixed" the issue by removing lines 12 and 13 here:
http://hg.mozilla.org/build/buildbot-configs/file/4f354feb8b2e/mozilla2/mobile/maemo5-gtk/mobile-browser/nightly/mozconfig#l12
After a rebuild, then pages load fine - no checkerboard
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•14 years ago
|
||
Could be some bad interaction with Breakpad and content processes. We don't have crash reporting hooked up yet to content processes (AFAIK), and MOZILLA_OFFICIAL controls whether crash reporting is enabled by default at runtime:
http://mxr.mozilla.org/mobile-browser/source/app/application.ini#23
Updated•14 years ago
|
tracking-fennec: --- → ?
Updated•14 years ago
|
tracking-fennec: ? → 2.0a1+
Comment 3•14 years ago
|
||
This bug basically makes it impossible to test Fennec on the n900, currently.
Comment 4•14 years ago
|
||
Are both processes being built the same way? I mean is there something that could be incompatible? The content process doesn't seem to even want to start talking to the main process
Do the symbols somehow mess up the IPC protocol?
Comment 5•14 years ago
|
||
I think it's the MOZILLA_OFFICIAL, not the symbols. Try this experiment:
Get a build that's failing to load pages. In the shell, export MOZ_CRASHREPORTER_DISABLE=1. Run the build, and see if it works. If so, the problem only appears when crash reporting is enabled.
Updated•14 years ago
|
Blocks: mobile-pool
Updated•14 years ago
|
Assignee: nobody → ted.mielczarek
Comment 6•14 years ago
|
||
Benjamin, do you know who can help with this bug?
Comment 7•14 years ago
|
||
(In reply to comment #5)
> I think it's the MOZILLA_OFFICIAL, not the symbols. Try this experiment:
> Get a build that's failing to load pages. In the shell, export
> MOZ_CRASHREPORTER_DISABLE=1. Run the build, and see if it works. If so, the
> problem only appears when crash reporting is enabled.
Disabling the crashreporter _did_ make remote pages load
Assignee | ||
Comment 8•14 years ago
|
||
I poked back into this code to prepare a todo list for enabling crash reporting for content processes, but I had forgotten that the exception handler is set up automatically when launching subprocesses. The hang is from ARENA_POISON_init() trying to AnnotateCrashReport() because GetEnabled() is true, but crashing because the annotation code isn't initialized (since it's OOP). We'll want that eventually, but for now this semi-workaround patch just makes GetEnabled() mean the same thing as for desktop firefox.
This doesn't "hook up" the crashreporter: we still need some code for content processes like this [1], this [2], and probably this [3].
[1] http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginModuleParent.cpp#134
[2] http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginModuleParent.cpp#262
[3] http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginModuleParent.cpp#190
Assignee: ted.mielczarek → jones.chris.g
Attachment #459733 -
Flags: review?(ted.mielczarek)
Comment 9•14 years ago
|
||
Comment on attachment 459733 [details] [diff] [review]
CrashReporter::GetEnabled() really means is the *in-process* crashreporter enabled (for now)
Do we want this as a permanent behavior switch? Currently the other API bits (like annotating) don't work in subprocesses anyway, so there's probably not much point.
r=me
Attachment #459733 -
Flags: review?(ted.mielczarek) → review+
Updated•14 years ago
|
Component: General → Breakpad Integration
Product: Fennec → Toolkit
QA Contact: general → breakpad.integration
Comment 10•14 years ago
|
||
Hrm, we're probably going to want annotations to work, remoting them to the chrome process. But for now, let's do whatever is expedient.
Comment 11•14 years ago
|
||
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 12•14 years ago
|
||
it seems that with this build I am unable to get a webpage to load:
http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2010-06-26-02-mobile-trunk-maemo5-gtk/
this is specific to a n900 as I can get it loaded on a linux desktop build.
Comment 13•14 years ago
|
||
(In reply to comment #12)
> it seems that with this build I am unable to get a webpage to load:
> http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2010-06-26-02-mobile-trunk-maemo5-gtk/
>
> this is specific to a n900 as I can get it loaded on a linux desktop build.
Works fine for me using the build here:
http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mozilla-central-maemo5-gtk/fennec-2.0a1pre.multi.linux-gnueabi-arm.tar.bz2
You need to log in
before you can comment on or make changes to this bug.
Description
•