Closed
Bug 1109793
Opened 9 years ago
Closed 7 years ago
Reproducible crash with e10s: sync XHR on unonload of MS support articles happens during CPOW message
Categories
(Core :: DOM: Content Processes, defect, P4)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
e10s | + | --- |
People
(Reporter: benjamin, Assigned: billm)
Details
(Keywords: crash, reproducible)
STR: * have e10s on * load http://support.microsoft.com/kb/3006625 in a browser tab * close that tab ENVIRONMENT: I have the following addons enabled: DOM Inspector Tree-style tabs Mass password reset Tree Style Tab ACTUAL: On page unload, the content process crashes like this: https://crash-stats.mozilla.com/report/index/a9ea679f-aa61-41d9-986a-ef3a42141210 This is caused by running the canunload event handler from within a CPOW, which in this case causes a sync XHR which spins the event loop and intentionally crashes since spinning an event loop from within a CPOW handler is verboten. I think we should have crashed earlier at either of the following locations: http://hg.mozilla.org/mozilla-central/annotate/5b01216f97f8/dom/events/EventDispatcher.cpp#l698 DispatchDOMEvent Or somewhere in the chain of EventListener::HandleEvent -> CallSetup::CallSetup -> JS::Call I don't know whether this is related to one of the addons or not... I'll try to test that later.
Reporter | ||
Comment 1•9 years ago
|
||
Bill, remind me why we couldn't crash earlier on event dispatch, instead of waiting for the content sync XHR to spin the event loop?
Flags: needinfo?(wmccloskey)
Assignee | ||
Comment 2•9 years ago
|
||
Too many add-ons want to dispatch an event in the content process. We were getting tons of crash reports from that. In every case I looked at, the add-on was making a new event and calling dispatchEvent using some content DOM node as the target.
Flags: needinfo?(wmccloskey)
Updated•9 years ago
|
Keywords: crash,
reproducible
Updated•9 years ago
|
Assignee: nobody → gkrizsanits
Comment 3•9 years ago
|
||
I installed DOM Inspector, Mass Password reset and Tree Style Tab from AMO. I couldn't find "Tree-style tabs" (is this a typo?). With these addosn and current nightly I couldn't reproduce this crash. Benjamin, can you please re-test?
Flags: needinfo?(benjamin)
Assignee | ||
Comment 4•9 years ago
|
||
This crash is definitely still possible. I think maybe I should take this bug.
Assignee: gkrizsanits → wmccloskey
Flags: needinfo?(benjamin)
Updated•9 years ago
|
Severity: normal → critical
Comment 5•9 years ago
|
||
back to my question in comment 3, Benjamin can you still reproduce this? After talking to Bill, this is theoretically possible, but that doesn't rise to the level of tracking it for milestone 6.
Flags: needinfo?(benjamin)
Reporter | ||
Comment 6•9 years ago
|
||
No, the STR in comment 1 don't reproduce this currently.
Flags: needinfo?(benjamin)
Updated•9 years ago
|
I haven't managed to reproduce this issue on the latest Aurora(46.0a2). I installed all specified add-ons, and after I closed the provided link, Firefox didn't crash. Also, Socorro does not show any more crashes with the same signature on the last 28 days. User Agent: Mozilla/5.0 (Windows NT 6.1; rv:46.0) Gecko/20100101 Firefox/46.0 Build ID: 20160205004003
Updated•8 years ago
|
Priority: -- → P4
Assignee | ||
Comment 8•8 years ago
|
||
This was fixed by CPOW cancellation I think.
Assignee | ||
Updated•7 years ago
|
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•