Closed Bug 578952 Opened 14 years ago Closed 14 years ago

Page doesn't load when electrolysis is enabled

Categories

(Toolkit :: Crash Reporting, defect)

Other
Other
defect
Not set
normal

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.
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
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
tracking-fennec: --- → ?
tracking-fennec: ? → 2.0a1+
This bug basically makes it impossible to test Fennec on the n900, currently.
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?
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.
Assignee: nobody → ted.mielczarek
Benjamin, do you know who can help with this bug?
(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
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 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+
Component: General → Breakpad Integration
Product: Fennec → Toolkit
QA Contact: general → breakpad.integration
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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
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.
(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
Depends on: 639725
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: