1154638 - framescripts sometimes get stuck with a "frozen" version of the DOM

Status: RESOLVED INVALID

(Core :: DOM: Navigation, defect)

Description

[Mark Hammond [:markh] [:mhammond]]

Attachment: show-link.js

Via bug 1151871, it's possible to navigate between pages such that frame scripts looking at content.document appear to see an old, "frozen" version of the DOM.

I haven't got a great repro yet, but I do have a convoluted one:

* Open a "browser" scratchpad and paste the attachment into it. It uses a framescript to get the href for a <link rel="canonical"> link for a page and dump()'s it. The canonical link should match the current URL - eg, try some random wikipedia articles and it always does.

* Open a Vimeo "staff picks" video, such as https://vimeo.com/channels/staffpicks/118972727.

* Run the script - note how the <link> and the actual URL agree.

* Under the video, click on any of the other videos in the series.

* Run the script again - now the <link> refers to the initial document, which is different from the current URL. Keep following such links and you get the same result. Refresh the page and it works.

Note that View->Source for the page shows the correct value, only the frame-script seems to be having trouble.

Dolske and I are speculating it is to do with the fact the pages use history.pushState (which I've confirmed with a debugger, and the page fails to navigate at all when browser.history.allowPushState=false) - but that might be wrong.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> Note that View->Source for the page shows the correct value

Yes, but that will refetch the source from the server based on the current URI of the docshell.  What does devtools show for the actual state of the DOM?

As in, if the page does a pushState but doesn't modify the DOM to look like the actual DOM of the URL it's pushing, then you'll get exactly the behavior you describe.

Comment 2

[Mark Hammond [:markh] [:mhammond]]

> As in, if the page does a pushState but doesn't modify the DOM to look like
> the actual DOM of the URL it's pushing, then you'll get exactly the behavior
> you describe.

Right - that's exactly what is happening.