Bug 1066433 (Remove simple mochitest event shim) has code that should take some events that are initiated in the content process and delivers them to the mochitest. It replaces a more hacky harness that had a similar effect. I believe I am seeing events not being forwarded to the mochitest. Specifically, browser_bug477014.js, when activated to run in e10s, times out waiting for a pageshow event, which seems to be initiated in the content process but is somehow lost before it makes it to the mochitest.

The test Jim was having a problem with was browser_thumbnails_bug818225.js. It calls addTab, which calls whenLoaded, which relies on a load event.

(In reply to Bill McCloskey (:billm) from comment #1) > The test Jim was having a problem with was browser_thumbnails_bug818225.js. > It calls addTab, which calls whenLoaded, which relies on a load event. Bug 698371 should hopefully merge tonight (on inbound now) after which the underlying thumbnailing code should be working correctly for remote browsers. After which you can test this by removing the skip-if rule for linux and running in e10s mode.

(In reply to Jim Mathies [:jimm] from comment #2) > (In reply to Bill McCloskey (:billm) from comment #1) > > The test Jim was having a problem with was browser_thumbnails_bug818225.js. > > It calls addTab, which calls whenLoaded, which relies on a load event. > > Bug 698371 should hopefully merge tonight (on inbound now) after which the > underlying thumbnailing code should be working correctly for remote > browsers. After which you can test this by removing the skip-if rule for > linux and running in e10s mode. Looks like this stuck this morning. I had to disable this test on all platforms due to random timeouts, so this test makes a great test case if you can reproduce locally.

(In reply to David Parks [:handyman] from comment #0) > Bug 1066433 (Remove simple mochitest event shim) has code that should take > some events that are initiated in the content process and delivers them to > the mochitest. It replaces a more hacky harness that had a similar effect. > > I believe I am seeing events not being forwarded to the mochitest. > Specifically, browser_bug477014.js, when activated to run in e10s, times out > waiting for a pageshow event, which seems to be initiated in the content > process but is somehow lost before it makes it to the mochitest. The pageshow event that is waiting for is the one fired from here, which runs in the main process: http://mxr.mozilla.org/mozilla-central/source/dom/base/nsFrameLoader.cpp#1354 I'm not entirely sure how that is supposed to work given that the remote frame has no docshell in the main process. Anyway I have a fix for that test in bug 1087966

(In reply to Dave Townsend [:mossop] from comment #4) > (In reply to David Parks [:handyman] from comment #0) > > Bug 1066433 (Remove simple mochitest event shim) has code that should take > > some events that are initiated in the content process and delivers them to > > the mochitest. It replaces a more hacky harness that had a similar effect. > > > > I believe I am seeing events not being forwarded to the mochitest. > > Specifically, browser_bug477014.js, when activated to run in e10s, times out > > waiting for a pageshow event, which seems to be initiated in the content > > process but is somehow lost before it makes it to the mochitest. > > The pageshow event that is waiting for is the one fired from here, which > runs in the main process: > http://mxr.mozilla.org/mozilla-central/source/dom/base/nsFrameLoader.cpp#1354 > > I'm not entirely sure how that is supposed to work given that the remote > frame has no docshell in the main process. Anyway I have a fix for that test > in bug 1087966 And now I spot that that function is only for non-remote loaders. The swap of remote loaders doesn't send the pageshow event at all.

I filed bug 1136478 for the fact that we're not firing pageshow events for remote docshell swapping. The issue with Jim's test is WFM.

Once this is fixed I think we can close this bug.