Intermittent browser_action_keyword.js | Uncaught exception - at :0 - Error: operation not possible on dead CPOW

RESOLVED FIXED in Firefox 47

Status

()

defect
P3
normal
Rank:
35
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: cbook, Assigned: dao)

Tracking

(Blocks 1 bug, {intermittent-failure})

unspecified
Firefox 47
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s+, firefox47 fixed)

Details

(Whiteboard: [fxsearch], )

Attachments

(1 attachment)

Rev4 MacOSX Snow Leopard 10.6 mozilla-inbound opt test mochitest-e10s-browser-chrome-1

https://treeherder.mozilla.org/logviewer.html#?job_id=8536070&repo=mozilla-inbound

07:15:34 INFO - 63 INFO TEST-UNEXPECTED-FAIL | browser/base/content/test/general/browser_action_keyword.js | Uncaught exception - at :0 - Error: operation not possible on dead CPOW
tracking-e10s: --- → ?
Component: General → Storage
Product: Firefox → Toolkit
This has nothing to do with Storage... We are clearly using a cpow when it's too late.
Component: Storage → General
Product: Toolkit → Firefox
it's something along these lines:

65   // Click on the result
66   info("Normal click on result");
67   let tabPromise = promiseTabLoadEvent(tab);
68   EventUtils.synthesizeMouseAtCenter(result, {});
69   let loadEvent = yield tabPromise;
70   is(loadEvent.target.location.href, "http://example.com/?q=something", "Tab should have loaded from clicking on result");

I think promiseTabLoadEvent is not e10s ready, apart that I don't know what else is using CPOWs here, we seem to fail just after resolving the load promise.
that could point out the problem is loadEvent.target.location.href, but I don't know internals good enough, maybe mconley can help.
Flags: needinfo?(mconley)
Yes - a CPOW does not keep a hard reference on what it's wrapping in another process, so it's possible that the event, event target, or event target location has been GC'd.

If it's important to examine the load event targets location href, you might try:

let loadPromise = ContentTask.spawn(tab.linkedBrowser, {}, function*() {
  yield new Promise((resolve) => {
    addEventListener("load", function onLoad(event) {
      removeEventListener("load", onLoad);
      resolve(event.target.location.href);
    });
  });
});

EventUtils.synthesizeMouseAtCenter(result, {});

let href = yield loadPromise;
is(href, "http://example.com/?q=something", "Tab should have loaded from clicking on result");


And if you end up doing that a few times, a helper function would probably make sense.
Flags: needinfo?(mconley)
Component: General → Location Bar
OS: Mac OS X → Unspecified
Priority: -- → P3
Hardware: x86 → Unspecified
Whiteboard: [fxsearch]
Rank: 35
Looks like this has gone away?
Flags: needinfo?(mak77)
I think comment 12 still applies, we should likely not directly access event.target.location.href but a bunch of tests are still doing that.

http://mxr.mozilla.org/mozilla-central/search?string=.target.location.href

Could be this doesn't happen anymore due to some timing change, but it still looks wrong.
Flags: needinfo?(mak77)
Posted patch patchSplinter Review
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #8726303 - Flags: review?(mconley)
Attachment #8726303 - Flags: review?(mconley) → review+
https://hg.mozilla.org/mozilla-central/rev/b8297417dfc4
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 47
You need to log in before you can comment on or make changes to this bug.