379105 - "ASSERTION: DOM window should always have a document" with XBL and <frame>

Status: RESOLVED WORKSFORME

(Core :: XBL, defect)

Description

[Jesse Ruderman]

###!!! ASSERTION: DOM window should always have a document!: 'domDoc', file /Users/jruderman/trunk/mozilla/toolkit/components/passwordmgr/base/nsPasswordManager.cpp, line 840

Steps to reproduce: unknown

This might be a regression from within the last week or two.

Comment 1

[Jesse Ruderman]

I have a testcase now.  I no longer think this is a regression.

The testcase triggers two assertions: one while loading, and one upon GC:

###!!! ASSERTION: DOM window should always have a document!: 'domDoc', file /Users/jruderman/trunk/mozilla/toolkit/components/passwordmgr/base/nsPasswordManager.cpp, line 840

###!!! ASSERTION: window not set for document!: 'Error', file /Users/jruderman/trunk/mozilla/layout/base/nsDocumentViewer.cpp, line 1245

It's interesting that I first noticed this because of an assertion in password manager rather than an assertion in core.  Should there be a similar assertion somewhere in core?

Comment 2

[Jesse Ruderman]

Attachment: testcase

Comment 3

[Boris Zbarsky [:bzbarsky]]

I really can't tell how we're getting into this state.  And since imo the appendChild call in question should be throwing, I'm disinclined to try to figure out exactly what's going on; we should just fix the real issue, which is that we can stick this frame in a stupid place.

Comment 4

[Jesse Ruderman]

Attachment: testcase that creates the <frame> using createElement

This testcase creates the <frame> using createElement, and still triggers both assertions.  So enforcing a rule "you may not move an element from the main document into an XBL shadow tree" would not take care of the problem reported here.

Comment 5

[Martijn Wargers (dead)]

I'm not getting any of these assertions in my mingw debug build.

Comment 6

[Jesse Ruderman]

WFM on trunk.

Comment 7

[Jesse Ruderman]

I checked in the second testcase as a crashtest.