Has anyone tried making src="javascript:..." iframes load asynchronously?

Dominic Cooney

unread,

Jul 26, 2016, 9:56:02 PM7/26/16

to blink-dev, Daniel Cheng, Kouhei Ueno

I noticed Firefox doesn't process javascript: iframe src URLs synchronously; Blink does (trace forward and backward from HTMLFrameElementBase::openURL.) So something like this:

<!DOCTYPE html>

<body>

let f = document.createElement('iframe');

f.src = 'javascript:console.log("b");';

console.log('a');

document.body.appendChild(f);

console.log('c');

f.remove();

document.body.appendChild(f);

</script>

prints a, c, b in Firefox but a, b, c, b in Blink.

What do you think about making these loads asynchronous? It would have a number of benefits:

- Be more like Firefox. (Not sure what other browsers do.)

- Comply with the spec, I think (see navigate step 12, which says to "queue a task.")

- Avoid a state where the parser is synchronously running script but hasn't set up its usual state of being blocked. (<-- I'm mostly interested in this, FWIW. I'm poking at script running for custom elements.)

- Be able to defer the load when loads are deferred or script is disallowed. Today I *think* we don't defer the load when loads are deferred, but do block the script--and never run it--if scripts are blocked. I think this might lead to some simplifications in navigation and loading.

This seems to me like an obvious thing to try, so I can only assume it won't work for some reason or we would have done it already. :) Does anyone have a sad story to tell?

Dominic

Daniel Cheng

unread,

Jul 26, 2016, 10:16:05 PM7/26/16

to Dominic Cooney, blink-dev, Kouhei Ueno

FWIW, Edge seems to have the same behavior as Firefox. I think we should try and see if we can make a similar change in Blink.

Daniel

Yoshifumi Inoue

unread,

Jul 26, 2016, 10:28:19 PM7/26/16

to Daniel Cheng, Dominic Cooney, blink-dev, Kouhei Ueno

+1 to follow Firefox and Edge.

Blink behavior is a food of ClusterFuzz.

2016年7月27日(水) 11:16 Daniel Cheng <dch...@chromium.org>:

Philip Rogers

unread,

Jul 26, 2016, 11:08:12 PM7/26/16

to Yoshifumi Inoue, Daniel Cheng, Dominic Cooney, blink-dev, Kouhei Ueno, Yoav Weiss

+1

Yesterday Yoav made a similar change to load data uri images asynchronously in https://crrev.com/d0c9ac3bf5bb4843c2c189a72e7b6c39e6743831.

Elliott Sprehn

unread,

Jul 27, 2016, 1:22:01 AM7/27/16

to Philip Rogers, Dominic Cooney, dch...@chromium.org, Kouhei Ueno, Yoav Weiss, blink-dev, Yoshifumi Inoue

Let's try it. At one point it made the world catch fire due to code that special cases Firefox vs WebKit (ex. Closure, a bunch of google3)... But if Edge is getting away with it maybe we can too. :)

Elliott Sprehn

unread,

Jul 27, 2016, 1:25:39 AM7/27/16

to Dominic Cooney, kou...@chromium.org, dch...@chromium.org, blink-dev

On Jul 26, 2016 9:56 PM, "Dominic Cooney" <domi...@chromium.org> wrote:
>
> I noticed Firefox doesn't process javascript: iframe src URLs synchronously; Blink does (trace forward and backward from HTMLFrameElementBase::openURL.) So something like this:
>
> <!DOCTYPE html>
> <body>
> <script>
> let f = document.createElement('iframe');
> f.src = 'javascript:console.log("b");';
>
> console.log('a');
> document.body.appendChild(f);
> console.log('c');
> f.remove();
> document.body.appendChild(f);
> </script>
>
> prints a, c, b in Firefox but a, b, c, b in Blink.
>
> What do you think about making these loads asynchronous? It would have a number of benefits:
>
> - Be more like Firefox. (Not sure what other browsers do.)
> - Comply with the spec, I think (see navigate step 12, which says to "queue a task.")
> - Avoid a state where the parser is synchronously running script but hasn't set up its usual state of being blocked. (<-- I'm mostly interested in this, FWIW. I'm poking at script running for custom elements.)

I'm pretty sure the parser can run script in parserRemoveChild and parserAppendChild for various other reasons. Where is this script running in the parser that you don't expect? I don't think changing javascript: urls makes this simpler.

- E

Dominic Cooney

unread,

Jul 27, 2016, 1:46:27 AM7/27/16

to Elliott Sprehn, Kouhei Ueno, Daniel Cheng, blink-dev

This is a bit of a tangent but I'm interested in your thoughts:

I was fixing random parser bugs in preparation for changing it for custom elements. The cause of one bug was the parser's assumption that if it had just processed a token, then if it is blocked it must be blocked because the treebuilder had a script to run. But that's not really a valid assumption. Blink will run scripts at lots of times for lots of reasons it turns out.

I'm thinking about representing the spec's "parser pause flag" more explicitly. Today it is "tree builder has an element to process" or "tree builder has handed an element off to the script runner which hasn't started it yet." I need to add "or custom element open tag encountered" to this mix.

Could you briefly enumerate the tree-modification-leads-to-synchronous-script-running things you're aware of? There's:

- script element insertion (predictably; although kouhei noticed an interesting bug with parser and multiple documents recently)

- iframes w/ javascript: src URLs.

- iframe unload event handlers

- Mutation Events (these are sometimes but not always deferred?)

- ???

Kouhei Ueno

unread,

Jul 27, 2016, 1:56:44 AM7/27/16

to Dominic Cooney, Elliott Sprehn, Daniel Cheng, blink-dev

+1

I think this change allows us to narrow down problem space. This is the only JS hook I'm aware of that's invoked on each parserAppendChild. Parser may invoke multiple parserAppendChild for a same Node from a single HTML token due to its "adoption agency algorithm", but the other possible JS entry points seems to provide only once.

--

kouhei

Dimitri Glazkov

unread,

Jul 27, 2016, 11:26:10 AM7/27/16

to Kouhei Ueno, Dominic Cooney, Elliott Sprehn, Daniel Cheng, blink-dev

This whole thread is amazing. Thank you for digging into this, Dominic.

:DG<

Dominic Cooney

unread,

Jul 27, 2016, 10:38:06 PM7/27/16

to Dimitri Glazkov, Kouhei Ueno, Elliott Sprehn, Daniel Cheng, blink-dev

On Thu, Jul 28, 2016 at 12:25 AM, Dimitri Glazkov <dgla...@chromium.org> wrote:

This whole thread is amazing. Thank you for digging into this, Dominic.

:DG<

Thank you. Credit due also to kouhei and dcheng; this is an idea we've been kicking around in Tokyo over the past week.

Reply all

Reply to author

Forward