This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23942 - 'load' is fired twice per spec for http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2668
Summary: 'load' is fired twice per spec for http://software.hixie.ch/utilities/js/live...
Status: RESOLVED INVALID
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-29 14:50 UTC by contributor
Modified: 2013-12-03 15:40 UTC (History)
4 users (show)

See Also:


Attachments

Description contributor 2013-11-29 14:50:52 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/
Multipage: http://www.whatwg.org/C#the-iframe-element
Complete: http://www.whatwg.org/c#the-iframe-element
Referrer: 

Comment:
'load' is fired twice per spec for
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2668

Posted from: 90.230.218.37
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.48 Safari/537.36 OPR/18.0.1284.26 (Edition Next)
Comment 1 Simon Pieters 2013-11-29 15:10:26 UTC
var iframe = document.createElement('iframe');
document.body.appendChild(iframe);

[[
When an iframe element is inserted into a document, the user agent must create a nested browsing context, and then process the iframe attributes for the "first time".
]]
http://www.whatwg.org/specs/web-apps/current-work/#the-iframe-element

[[
Otherwise, if the element has no src attribute specified, and the user agent is processing the iframe's attributes for the "first time"
Queue a task to run the iframe load event steps.
]]
http://www.whatwg.org/specs/web-apps/current-work/#process-the-iframe-attributes

OK so now we have 'iframe load event steps' on the event queue, and continue the script:

var doc = iframe.contentDocument;
doc.write('x');

This implies open() which, among other things, says...

[[
If the Document's iframe load in progress flag is set, set the Document's mute iframe load flag.
]]
http://www.whatwg.org/specs/web-apps/current-work/#dom-document-open

The iframe load in progress flag is not set, so we don't set the mute iframe load flag here.

Moving on...

doc.close();

This inserts EOF and runs the tokenizer, which I think will cause a 'load' event to be fired as part of http://www.whatwg.org/specs/web-apps/current-work/#stop-parsing

Next we spin the event loop and do this:

[[
The iframe load event steps are as follows:

Let child document be the active document of the iframe element's nested browsing context.

If child document has its mute iframe load flag set, abort these steps.

Set child document's iframe load in progress flag.

Fire a simple event named load at the iframe element.

Unset child document's iframe load in progress flag.
]]
http://www.whatwg.org/specs/web-apps/current-work/#iframe-load-event-steps

Which also fires a 'load' event.
Comment 2 Simon Pieters 2013-11-29 15:15:48 UTC
(In reply to Simon Pieters from comment #1)
> doc.close();
> 
> This inserts EOF and runs the tokenizer, which I think will cause a 'load'
> event to be fired as part of
> http://www.whatwg.org/specs/web-apps/current-work/#stop-parsing

Hmm, that fires 'load' on the window, not on the iframe. So maybe there's no spec bug here...
Comment 3 Ian 'Hixie' Hickson 2013-12-02 20:09:38 UTC
As far as I can tell, this matches browsers.