iframe.goBack() doesn't paint the previous pipeline

[paulrouget]

STR:

• load test case (see "foo")
• click on "go to next page" (see "bar")
• click on goBack

"foo" should show up.

<!-- dom.mozbrowser.enabled needed -->
<iframe style="display:block;width:300px;height:300px" mozbrowser="true" src="data:,foo"></iframe>
<button onclick="f.src = 'data:,bar'">go to next page</button>
<button onclick="f.goBack()">goBack</button>
<button onclick="f.goForward()">goForward</button>
<script>
  var f = document.querySelector("iframe");
</script>

[paulrouget]

So first, I think we revoke paint permission of the wrong pipeline:

servo/components/compositing/constellation.rs

Line 1614 in 5b28a41

// Revoke paint permission from a pipeline, and all children.

Here we traverse the frame tree, but the top level frame of that tree should not use pipeline(frame.current) but pipeline(pipeline_id). Or, revoke_paint_permission should be called before the new pipeline is set to frame.current.

But that's apparently not enough.

The right frame tree is sent to the compositor. Paint permissions appear to be properly set.

With WR, the old page is not replace by the new one.
Without WR, the new page is replaced by a blank page.

[jdm]

cc @glennw

[glennw]

@paulrouget I'm not sure I understand what's wrong with that code. On the first iteration through that loop, pipeline_id should be equal to frame.current - is it not? From there it should loop through any iframes in the free tree from that root. The iframe goBack() code certainly used to work and I don't think that part has changed for quite some time, so I suspect a regression elsewhere.

[paulrouget]

On the first iteration through that loop, pipeline_id should be equal to frame.current - is it not?

If I understand correctly how this works, it is not.

frame.current is set to next (which is correct), and then we call revoke_paint_permission(prev) (which is correct), but within revoke_paint_permission, we use frame.current.

[paulrouget]

regression: c72d0c2

[paulrouget]

@pcwalton any idea what might have gone wrong with c72d0c2?

Also - related (fixed) issue: #8081

[pcwalton]

@paulrouget Should be fixed by #10159.

[paulrouget]

follow up for the revoke_paint_permission thing: #10162

[pcwalton]

Can we close this in favor of #10162, in the absence of known actual browser.html problems this is causing?

[paulrouget]

So this is fixed.

#10162 doesn't cause any bug afaict. Just thought I filed it just in case.

[paulrouget]

Sorry, not fixed, I though #10159 landed.

[pcwalton]

Oh right, sorry about that.