615031 - "ASSERTION: Could not get loadgroup; onload may fire too early"

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Jesse Ruderman]

Attachment: testcase

###!!! ASSERTION: Could not get loadgroup; onload may fire too early: 'loadGroup', file content/base/src/nsContentUtils.cpp, line 2517

Comment 1

[Jesse Ruderman]

The testcase makes a fuzzPrivGC call, so you'll need to install
https://www.squarefree.com/extensions/domFuzzLite.xpi to test it.

Comment 2

[Jesse Ruderman]

Attachment: stack trace

Comment 3

[Boris Zbarsky [:bzbarsky]]

Hmm.  Should nsDataDocumentContentPolicy perhaps deny loads for non-data documents whose scope object has gone away?

Or should documents whose scope object has gone away start claiming to be data documents?

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

> Or should documents whose scope object has gone away start claiming to be data
> documents?

The main issue I can think of is that it exposes GC behavior.

Shouldn't holding on to the document really be holding the scope and the .frameElement alive? You should be able to access it using document.defaultView.frameElement, no?

Comment 5

[Boris Zbarsky [:bzbarsky]]

> The main issue I can think of is that it exposes GC behavior.

Does it?  We should be tearing down the frameloader synchronously (or close to it) when the frame element is removed from the document.  That should kill the dochell and global window (in the sense of calling Destroy, not destructors), which should SetScriptGlobalObject(null) on the document.  All of this independent of the GC.

The loadgroup is gotten via the document->docshell reference, so if we can't get it that means that reference has been broken... and it shouldn't be broken until the same time as the document loses its window.

Note that .defaultView is also null in this case, for the same reasons: we tear down all the window-related machinery when the frameloader goes away.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Ah, ok. Then the second paragraph in comment 3 sounds good to me.

Comment 7

[Boris Zbarsky [:bzbarsky]]

I wonder whether there could be web compat issues there.  For example, right now someone could grab a document out of a subframe, createElement an HTML <img>, set its src and then it would, I think, load... and then they could draw it into a canvas or whatnot.

That's a problem with both solutions proposed in comment 3, btw.

Comment 8

[Jesse Ruderman]

Attachment: updated testcase

Updated to work with https://www.squarefree.com/extensions/domFuzzLite3.xpi

Comment 9

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.