Bug 14568 – load event can fire prematurely for frameless documents (affects Acid3?)

• Status: NEW
• Component: Page Loading

[Geoffrey Garen]

FrameLoader tracks loading progress. Without a FrameLoader, a Document doesn't know whether loading is in progress. Therefore, a Document might end up dispatching the load event too early.

This is the responsible code, in Document.cpp:

void Document::close()
{
    Frame* frame = this->frame();
    if (frame) {
        // This code calls implicitClose() if all loading has completed.
        FrameLoader* frameLoader = frame->loader();
        frameLoader->endIfNotLoadingMainResource();
        frameLoader->checkCompleted();
    } else {
        // Because we have no frame, we don't know if all loading has completed,
        // so we just call implicitClose() immediately. FIXME: This might fire
        // the load event prematurely.
        implicitClose();
    }
}

I don't know if this is a real-world problem or not.

[David Kilzer (:ddkilzer)]

See Bug 15170, Bug 15805 and Bug 16097.

[Eric Seidel (no email)]

I think this might be related to our @font-face load-event problems with Acid3.  I'm not certain of that though.

[Alexey Proskuryakov]

Is this still an issue? Could you please attach a test case?

[Stephen Chenney]

This code still appears in a crash stack. Load http://www.speckproducts.com/ in a debug build of Chrome (and probably Safari too) and you will hit an assert due to an onload event firing during an SVG font load. I have yet to reduce it to a Layout test, and as I am unfamiliar with how all this works, I find it rather challenging. 

On the other hand, just because the code goes through this path does not mean it's a problem. There should not be any onload event until after the font has loaded _and_ the calling code has finished layout, which seems impossible to track. We also believe that an SVG font externally loaded should not be able to invoke script in the first place.

[Myles C. Maxfield]

This causes a crash in CSSSegmentedFontFace::getFontData() due to the function getting called inside itself. (The load events run Javascript which causes a layout which ends up calling the function again)

[Alexey Proskuryakov]

Frameless documents can't load subresources, so I think that the comment is incorrect, and the bug is invalid.

What Myles is referring to is that implicitClose() dispatches pending load events on ALL documents, as it calls these static functions:

    ImageLoader::dispatchPendingBeforeLoadEvents();
    ImageLoader::dispatchPendingLoadEvents();
    ImageLoader::dispatchPendingErrorEvents();

    HTMLLinkElement::dispatchPendingLoadEvents();
    HTMLStyleElement::dispatchPendingLoadEvents();

This is outright crazy, and does cause problems due to running JS at inopportune time. I'm not sure whether the frameLoader->checkCompleted() code path has the same problem (i.e. whether it ends up synchronously calling implicitClose() too).

[Andreas Kling]

(In reply to comment #6)
> Frameless documents can't load subresources, so I think that the comment is incorrect, and the bug is invalid.
> 
> What Myles is referring to is that implicitClose() dispatches pending load events on ALL documents, as it calls these static functions:
> 
>     ImageLoader::dispatchPendingBeforeLoadEvents();
>     ImageLoader::dispatchPendingLoadEvents();
>     ImageLoader::dispatchPendingErrorEvents();
> 
>     HTMLLinkElement::dispatchPendingLoadEvents();
>     HTMLStyleElement::dispatchPendingLoadEvents();

Could we pass the Document* to these things and make them dispatch document-local events only? Would that solve the issue? I don't understand why they work globally.

[Alexey Proskuryakov]

The SVG issue is now tracked as bug 136269.