1844517 - NavigationManager should not generate navigation ids for document.open/write/close

Status: NEW

(Remote Protocol :: Agent, defect, P2)

Description

[Julian Descottes [:jdescottes]]

With the current WebProgressListener APIs, we have no way to differentiate a same hash navigation (https://example.com/#foo -> https://example.com/#foo) from someone using document APIs such as:

      document.open();
      document.write("<h1>Replaced</h1>");
      document.close();

However, according to the spec the second use case should not lead to a new navigation id for the current document. And more importantly we need to be able to differentiate the two in order to avoid emitting the event browsingContext.fragmentNavigated if document.open/write/close is used.

Comment 1

[Julian Descottes [:jdescottes]]

WebProgress logs for both actions are:

[Parent 78809: Main Thread]: I/BCWebProgress OnLocationChange({isTopLevel:1, isLoadingDocument:0}, <null>, http://example.com/#foo, LOCATION_CHANGE_SAME_DOCUMENT) on {top:1, id:14, url:http://example.com/#foo}

Olli, do you know if we could have another flag to know if the location change came from document.open/write/close? We need to exclude those in some cases in WebDriver BiDi, and right now they are impossible to distinguish from a same-url+same-hash navigation

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

I'm surprised that those make any different in WebDriver BiDi.

But we could add another argument to UpdateURLAndHistory and then pass that here https://searchfox.org/mozilla-central/rev/8d43262674d6c6d469b821cca579b1240ebb42a5/docshell/base/nsDocShell.cpp#11620,11634
And create a new flag telling that the location change is for document.open.
Something like that should work.

Comment 3

[Julian Descottes [:jdescottes]]

I'm surprised that those make any different in WebDriver BiDi.

Yes, :jgraham mentioned that another option was to update BiDi and align what happens on document.open with other same document navigations.

Alex: since puppeteer is a known user of document.open, if document.open would have its own navigation id, and would emit fragmentNavigated events ... how would that work for you? Would it make puppeteer's life easier, harder?

Comment 4

[alexrudenko]

I think the events document.open/write/close should have ID of the navigation that initially created the doc and the fragmentNavigated event would be unexpected as there is no fragment navigation happening. FWIW in CDP there is a dedicated event Page.documentOpened to indicate that the document was opened but in Puppeteer we don't depend on it. So having no fragmentNavigated event but only load and dom content loaded with the ID of the original navigation would be sufficient for Puppeteer I think.

Comment 5

[James Graham [:jgraham]]

So, long term, I think it would make sense for WebDriver BiDi to align with the DOM Navigation API. AFAICT that one more or less assigns an ID for anything that results in a new session history entry. So IIUC that would be consistent with fragment navigation getting a navigation id, but document.open not getting a new ID.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I don't think this currently blocks Puppeteer tests that are needed for the final announcement? If I'm wrong lets get it back into M10 but otherwise lets leave in the backlog for now.