"ASSERTION: Inner window supports nsWrapperCache, fix WrapObject!"

VERIFIED FIXED in Firefox 32

Status

()

--
critical
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: jruderman, Assigned: peterv)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
mozilla33
x86_64
Mac OS X
assertion, regression, sec-high, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox31 unaffected, firefox32 verified, firefox33 verified, firefox-esr24 unaffected, b2g-v1.3 unaffected, b2g-v1.3T unaffected, b2g-v1.4 unaffected, b2g-v2.0 fixed, b2g-v2.1 fixed)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Created attachment 8431438 [details]
j.html

1. Create a profile
       with the prefs:
           user_pref("dom.min_background_timeout_value", 4);
           user_pref("dom.disable_open_during_load", false);
       and the extension:
           https://www.squarefree.com/extensions/domFuzzLite3.xpi

2. Run with the testcase filename on the command line
       (You might have to repeat step 2 a few times.)

###!!! ASSERTION: Inner window supports nsWrapperCache, fix WrapObject!: 'IsOuterWindow()', file dom/base/nsGlobalWindow.h, line 354
   (This assertion was added in bug 693301.)

###!!! ASSERTION: EnsureInnerWindow called on inner window: 'IsOuterWindow()', file dom/base/nsPIDOMWindow.h, line 331
(Reporter)

Comment 1

5 years ago
Created attachment 8431439 [details]
stack for the first assertion
(Assignee)

Comment 2

5 years ago
We're firing the DOMContentLoaded event for "missing-1" (actually for the error page for that) but we've already collected the inner window for it.
(Assignee)

Comment 3

5 years ago
The exact same thing happens with XPConnect reflectors for Window, but SetParentToWindow returns an error if the nsGlobalWindow doesn't have a wrapper anymore.
(Assignee)

Comment 4

5 years ago
Created attachment 8432401 [details] [diff] [review]
v1
Assignee: nobody → peterv
Status: NEW → ASSIGNED
Please adjust the rating as appropriate.  I assume this is a regression from Window WebIDL.
Blocks: 789261
status-firefox31: --- → unaffected
status-firefox32: --- → affected
Keywords: sec-high
(Assignee)

Comment 6

5 years ago
Created attachment 8435783 [details] [diff] [review]
v1
Attachment #8432401 - Attachment is obsolete: true
Attachment #8435783 - Flags: review?(bzbarsky)
Comment on attachment 8435783 [details] [diff] [review]
v1

r=me
Attachment #8435783 - Flags: review?(bzbarsky) → review+
https://hg.mozilla.org/mozilla-central/rev/4b7010671a27
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
status-b2g-v1.3: --- → unaffected
status-b2g-v1.3T: --- → unaffected
status-b2g-v1.4: --- → unaffected
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → fixed
status-firefox33: --- → fixed
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
(Assignee)

Comment 10

5 years ago
Comment on attachment 8435783 [details] [diff] [review]
v1

Ugh, this missed the branching.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 789261
User impact if declined: probably crashes/security issues
Testing completed (on m-c, etc.): landed on m-c
Risk to taking this patch (and alternatives if risky): low-risk, just makes us deal with a situation that we thought couldn't happen
String or IDL/UUID changes made by this patch: none
Attachment #8435783 - Flags: approval-mozilla-aurora?
Comment on attachment 8435783 [details] [diff] [review]
v1

Aurora approval granted.
Attachment #8435783 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-b2g-v2.0: affected → fixed
status-firefox-esr24: --- → unaffected
Confirmed assert/crash on Fx32, 2014-05-30.
Verified fixed on Fx32, 2014-07-14.
Verified fixed on Fx33, 2014-07-07.
Status: RESOLVED → VERIFIED
status-firefox32: fixed → verified
status-firefox33: fixed → verified
Group: core-security
Keywords: regression
You need to log in before you can comment on or make changes to this bug.