When trying to land bug 865745 (a major platform refactoring involving JSContexts), I ran into a failure in mochitest-metro-chrome (see bug 865745 comment 29). The failure comes when we try to access aBrowser.__SS_extdata during teardown, which is undefined: http://mxr.mozilla.org/mozilla-central/source/browser/metro/components/SessionStore.js#374 I hypothesized that we'd always thrown here, and that the platform changes just cause us to report the exception to onerror where we previously squelched it. To confirm my theory, I pushed a diagnostic patch to add a try/catch block and dump() whether we throw in in onTabClose. I pushed one with the JSContext changes, and one without: https://tbpl.mozilla.org/?tree=Try&rev=d0d7d9cabe88 https://tbpl.mozilla.org/?tree=Try&rev=97f6732f7f45 In both cases, the log shows the following: INFO - TEST-INFO | chrome://mochitests/content/metro/browser/metro/base/tests/mochiperf/browser_msgmgr_01.js | END msg manager 3 INFO - Threw retrieving extData INFO - Threw retrieving extData INFO - Didn't throw retrieving extData INFO - INFO TEST-END | chrome://mochitests/content/metro/browser/metro/base/tests/mochiperf/browser_msgmgr_01.js | finished in 7852ms This confirms my theory. And since we've always thrown here, we don't need to block bug 865745 on sorting this out. I'm pushing bug 865745 along with a patch to squelch the exception (which effectively mimics the old behavior). This allows the metro team to dig into this on their own time (if they want to at all).

Why is __SS_extdata undefined?

(In reply to Jim Mathies [:jimm] from comment #1) > Why is __SS_extdata undefined? Nm that. I see this is in our session restore code. We haven't done much work with this. I imagine it's a timing issue since this test runs for a very short period of time.

Mass close of bugs in obsolete product https://bugzilla.mozilla.org/show_bug.cgi?id=1350354