Make same-origin navigations use the same script task

[jdm]

This yields better resource conservation, and is important for iframe navigation spec-compliance in particular.

Blocks #5236.

[jdm]

Relevant code: Constellation::handle_load_url_msg.
Currently we always create a new script task (see the None argument to new_pipeline). We want to use the same heuristic as handle_script_loaded_url_in_iframe.

[jdm]

Oh, this isn't as easy as I suspected at first. This task basically involves adapting the AttachLayout message that the constellation sends to script - currently it's only used for a new iframe being added to a page. We want the constellation/script task to support the following cases:

• adding a new iframe
• replacing an existing iframe's contents
• replacing a top-level document

[benschulz]

I'd like to work on this.

[jdm]

Please do :)

[KiChjang]

@benschulz Ping

[benschulz]

I haven't gone past analysis on this one. So if you want to "steal" it, feel free. ;)

[KiChjang]

I was simply curious of the status of this issue. As of now though, it might be better to instead wait for #8658 to land before attempting this issue.

Would you still like to pursue tackling this issue once #8658 lands?

[benschulz]

Sure. I'll give a ping when I start work on it, in case someone else is looking for an issue to work on before I get to it. ;)

[KiChjang]

I suspect that the heavy-lifting is going to be done in script_thread::handle_new_layout when adapting AttachLayout to this new design. I'm guessing that handle_new_layout would behave a bit differently depending on the nature of the navigation. What should this function's behaviour look like when 1) a new, same-origin iframe is being added 2) an existing iframe is being replaced with same-origin content 3) navigating towards a same-origin destination in a top-level browsing context?

[asajeffrey]

See #633.

[asajeffrey]

Clsoed by #14211.