When an iframe loads a new page, dirty and reflow it so that the layout fragment will pick up the new subpage ID.

[pcwalton]

This is necessary to make its new contents show up!

Closes #8081.

r? @jdm

cc @paulrouget @glennw

[pcwalton]

cc @metajack as well.

[eefriedman]

The page shouldn't actually be changing visibly until around step 22 of the navigate algorithm, after we see the initial response from the server (https://html.spec.whatwg.org/multipage/browsers.html#navigating-across-documents). This patch marks the iframe dirty and forces a reflow around step 10 or so.

I'm not completely sure whether that indicates a problem with your patch or a more general architectural issue.

[pcwalton]

I think the correct solution to that is to not update the iframe DOM node's stored subpage ID until the right time. Relying on the timing of dirty bits and reflows is wrong since those can be set or can happen for lots of reasons.

In other words I think that's a preexisting problem independent of this patch.

[Ms2ger]

Why is the force_reflow necessary exactly? It would be nice to have documentation so I could figure out when it's necessary from first principles rather than having to take it on faith.

[pcwalton]

I'll see if I can use reflow instead of force reflow.

Renaming force reflow and reflow seems out of scope for this patch.

[pcwalton]

Updated to use reflow instead of force_reflow. r? @jdm

[jdm]

@eefriedman is right. I think this actually intersects with #8612, and we should piggy-back off of that work. I propose we add a Constellation->Script message called FramedContentChanged, which is sent to the script task for the framing pipeline. This will mark the iframe element as dirty and initiate the reflow, and will be sent from the code in the constellation that receives the ActivateDocument message in #8612.

[pcwalton]

#8612 seems blocked for whatever reason. Status?

[jdm]

@glennw and I decided to go with his proposed simple solution in that PR last week.

[glennw]

I implemented the simple solution yesterday. But when I ran WPT tests a heap of unexpected failures occurred. I suspect it's exposing a different race, but perhaps there is a bug in the implementation. I'll try to look into it again today.

[bors-servo]

☔ The latest upstream changes (presumably #8618) made this pull request unmergeable. Please resolve the merge conflicts.

[glennw]

@pcwalton @jdm #8612 has landed now, if that was still blocking further work here.

[metajack]

@pcwalton This is the last known P1 browser.html blocker, so let's get this rebased an landed.

[pcwalton]

Superseded by #9285.