Steps To Reproduce: 1. Make sure e10s, set browser.tabs.remote.autostart = true and restart 2. Tab Crashed 3. Open about:crashes and Click a crash ID to open "mozilla crash reports" 4. Click one of link "Bugzilla - Report this bug in". Actual Results: New tab opened, but nothing load in the tab Expected Results: Bugzilla should be loaded

When I click one of link "Bugzilla - Report this bug in". An error shown in Error Console: Error: NS_ERROR_ABORT: User canceled master password entry Source File: resource://gre/components/crypto-SDR.js Line: 163

For example, Tab crash ID bp-c56bfe23-187e-4e61-8584-13a292140722 bp-cbdc8a9d-7a85-462c-8916-eca562140722

The fact that the link clicks don't work is bug 1047603. That being said, we should also probably move about:crashes to the content process.

about:crashes does require chrome privs, FWIW.

Comment on attachment 8472499 [details] [diff] [review] Make it possible to transition from non-remote to remote browsers while browsing away from about: pages. r=? Hey Blake, How do you feel about this solution? This makes it possible to transition from non-remote browsers on about: pages to remote browsers when the location changes to a remote-able URI. This will fix the reporters bug, though doesn't fix the underlying issue of being able to open non-remote tabs from non-remote tabs in an e10s window.

Comment on attachment 8472499 [details] [diff] [review] Make it possible to transition from non-remote to remote browsers while browsing away from about: pages. r=? Are you comfortable reviewing this, billm?

remote: https://hg.mozilla.org/integration/fx-team/rev/893fa8436b70

Backing out due to bug 1056438: remote: https://hg.mozilla.org/integration/fx-team/rev/e5a507b9a576

So this seemed to cause a few problems: 1) Bug 1056438 - if about:addons, or any non-remote tab was in a session that is restored, session restore would break. 2) bjacob, ehsan and I noticed that in debug builds, if we killed and restored a session, we'd fail this assertion: MOZ_ASSERT(mBlockDOMContentLoaded); from: http://hg.mozilla.org/mozilla-central/file/dac8b4a0bd7c/content/base/src/nsDocument.cpp#l4928 which, according to ehsan, is highly undesirable.

(In reply to Wes Kocher (:KWierso) from comment #12) > https://hg.mozilla.org/mozilla-central/rev/e5a507b9a576 This bug should stay in "REOPENED".

(In reply to Alice0775 White from comment #13) > (In reply to Wes Kocher (:KWierso) from comment #12) > > https://hg.mozilla.org/mozilla-central/rev/e5a507b9a576 > > This bug should stay in "REOPENED". Yeah, messed up the mc-merge script for some stuff.

(In reply to Mike Conley (:mconley) from comment #11) > So this seemed to cause a few problems: > > 1) Bug 1056438 - if about:addons, or any non-remote tab was in a session > that is restored, session restore would break. > 2) bjacob, ehsan and I noticed that in debug builds, if we killed and > restored a session, we'd fail this assertion: 3) It broke mochitest-e10s-2 on gtk3 builds on elm: - turned red when landing the merge containing this patch https://tbpl.mozilla.org/?tree=Elm&rev=27440eb3e1c3 - turned back orange (yeah, orange is the "normal" color on those builds) when landing the merge of the backout https://tbpl.mozilla.org/?tree=Elm&rev=6ca50c5d0437 - bisected on try: https://tbpl.mozilla.org/?tree=Try&rev=42e4162ca647 last good https://tbpl.mozilla.org/?tree=Try&rev=42e8bb33926f first bad (disregard the first debug mochitest-e10s-2 red, it was triggered manually and didn't actually use the debug build) It would be interesting to know why those turned red when they didn't on other platforms.

I guess I should paste the failures: 3165 INFO TEST-UNEXPECTED-ERROR | /tests/dom/base/test/test_Image_constructor.html | Assertion count 2 is greater than expected range 0-0 assertions. 3251 INFO TEST-UNEXPECTED-FAIL | /tests/dom/base/test/test_bug1043106.html | Test timed out.

I have a patch that cleans up transitions between non-remote and remote browsers that fixes this.

This bug should be fixed for the e10s M2 milestone.

This is going to be fixed by bug 1047603.

That solves the user impact of the issue, I filed bug 1066694 to track the remaining problem.