Closed Bug 1151864 Opened 9 years ago Closed 8 years ago

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

Categories

(Firefox :: Address Bar, defect, P3)

Product:
Firefox
Component:
Address Bar
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 47
Tracking Flags:
Tracking Status
e10s + ---
firefox47 --- fixed

People

(Reporter: cbook, Assigned: dao)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: intermittent-failure, Whiteboard: [fxsearch])

Attachments

(1 file)

patch
1.98 KB, patch
mconley
: review+
Details | Diff | Splinter Review 
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)
Attached patch patch — — Splinter 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: 8 years ago

          status-firefox47:
          --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 47

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: