1010737 - Windows tests that use CPOWs when clicking buttons crash

Status: RESOLVED DUPLICATE of bug 1056018

(Core :: IPC, defect, P2)

Description

[Jim Mathies [:jimm]]

Attachment: win32 stack

Spun off from bug 691601 - stack attached. When a browser mochitest invokes a click handler on a button, focus changes and the puppet widget attempts to sync request some IME related information. The ipc channel aborts on this sync call within a sync call in the child process.

Comment 2

[Martijn Wargers (dead)]

I see this happening while trying to run: ./mach mochitest-browser browser/base/content/test/chat/browser_focus.js --e10s
127 INFO [Child 52029] ###!!! ABORT: sync messages forbidden while handling urgent message: file /Users/mwargers/mozilla-central/ipc/glue/MessageChannel.cpp, line 1739
128 INFO ###!!! ERROR: Potential deadlock detected:

Comment 5

[Chris Peterson [:cpeterson]]

Moving old M2 P2 bugs to M4.

Comment 6

[Chris Peterson [:cpeterson]]

Move old M2's low-priority bugs to M6 milestone.

Comment 7

[Chris Peterson [:cpeterson]]

oops: old M2 P2 bugs should have been moved to new M4 milestone, not M6.

Comment 8

[Jim Mathies [:jimm]]

Hey bill, I'm curious how bug 1049879 allows us to skip over this? With a cpow on the stack and asserting sync outcall, I'm curious how we adjust priorities here to avoid the assert.

Comment 9

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

We need to raise the priority of IME messages to "urgent". That's one level above what CPOW messages are sent at (which is "high"). That means that the parent will handle the IME message while it's waiting for the CPOW response.

The general rule now for avoiding these assertions is that you can only send messages of higher priority than the one you're currently handling. For messages of "high" priority, we also allow same-priority nesting.

Comment 10

[Allison Naaktgeboren :ally]

billm believes this has been fixed by bug 1056018. So let's run the tests and find out

Comment 11

[Allison Naaktgeboren :ally]

tests run. 

Under e10s & non e10s both fail with an identical series of "Uncaught Exception TypeError: Promise.defer is not a function"

No aborts, no stacks. Maybe some one should re-enable the test in browser.ini?