I am creating this bug in follow-up to https://twitter.com/tpillard/status/1028663435524009984
const root = document.body;
const frame = document.createElement('iframe');
const href = 'https://bugs.webkit.org';
frame.onload = (evt) => console.log('Loaded', evt);
frame.src = href;
Inverting the last two lines (setting the frame's src before appending it to the DOM) fixes the problem.
Tested and fixed with the following UA string:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1.1 Safari/605.1.15
I've originally had some customer complaints on this behavior, one includes the following UA string:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1 Safari/605.1.15
While debugging, I noticed similar issues have been reported by users on StackOverflow over the years:
I could not reproduce this behavior on other browsers I had at my disposal.
Thank you for any response,
Setting the `load` event handler on the iframe after appending it to the DOM fixes the problem as well.
Created attachment 347527 [details]
On interesting, When an iframe is inserted into a document, it loads about:blank which in turn fires a load event. What makes WebKit and Blink's behavior different from the spec is that we synchronously fire a load event in this case.
When an iframe element is inserted into a document that has a browsing context, the user agent must create a new browsing context, set the element's nested browsing context to the newly-created browsing context, and then process the iframe attributes for the "first time".
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.
The task source for this task is the DOM manipulation task source.
My guess is that making the event load fire async won't be a Web compatible change at this point but we can try.