Add browsingContext event to monitor history API usage

[juliandescottes]

Current browsingContext events only cover regular page navigation or fragment navigation (navigationStarted, fragmentNavigated, ...)

For parity with https://chromedevtools.github.io/devtools-protocol/tot/Page/#event-navigatedWithinDocument we could also expose additional events for history API usage.

[jgraham]

We previously had https://github.com/w3c/webdriver-bidi/issues/402 in which I suggested fragmentNavigated should cover this use case. But APIs like pushState() don't end up going through the navigation path in HTML and so aren't covered by that event as specified at present. So there are two options here:

• Change HTML so that we emit fragmentNavigated for anything that changes the position in the session history without changing the active document.
• Add a new event, specifically for the case where there isn't an actual navigation, but something is using one of the DOM APIs to create new history entries.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed History navigation events, and agreed to the following:

• ACTION: David - Make sure agenda is ready ahead of time and organsie the remote participation links [1]
• ACTION: Orkon - Collect these properties needed and put it in the issue with use cases of how people would use it [2]

The full IRC log of that discussion

<AutomatedTester> topic: History navigation events
<AutomatedTester> github: https://github.com/w3c/webdriver-bidi/issues/502
<AutomatedTester> jgraham: the question here is how do we want to expose history navigation in the API
<AutomatedTester> ... at the moment we have specific events
<AutomatedTester> ... for history and for fragments
<AutomatedTester> ... we don't have any events for the old history or the new history API in the browser. The latter is only in chromium
<AutomatedTester> ... so how should we expose this to an API? Should we have 1 event or map to a DOM event?
<AutomatedTester> q?
<orkon> q+
<AutomatedTester> ack next
<AutomatedTester> orkon: in CDP we don't distinguish between fragments and history
<AutomatedTester> ... we only have 1 type of event that people can listen to
<AutomatedTester> ... I don't think we have a usecase for more detailed events than that
<AutomatedTester> q?
<simonstewart> q+
<AutomatedTester> automatedtester: jgraham do you want to see what CDP is doing and see if that is sufficient?
<AutomatedTester> jgraham: yea maybe, I can see some cases where we want different types of events
<AutomatedTester> ... and puppeteer could always take the different events and map it to a single API
<orkon> q+
<AutomatedTester> ... I think we should make sure that we design it forward looking as much as possible
<AutomatedTester> ack next
<AutomatedTester> simonstewart (IRC): speaking with my selenium hat on I think having a single event type is much easier DX for our users
<AutomatedTester> ... and it is easier to implement and the exact opposite of jgraham was saying
<AutomatedTester> ack next
<AutomatedTester> orkon: I am not up to date with the new API and I wonder if there are ways we can do this with script evaluation
<AutomatedTester> jgraham: I think there are ways to do it but not sure they are sensible and it would be better to expose this directly in our API
<AutomatedTester> ... e.g. if we wanted to do a task after a history event has completed they could do it even if it wasnt initiated via a webdriver API
<AutomatedTester> q?
<orkon> present-
<AutomatedTester> rrsagent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2023/08/09-webdriver-minutes.html AutomatedTester
<jgraham> rrsagent: bye
<RRSAgent> I see 2 open action items saved in https://www.w3.org/2023/08/09-webdriver-actions.rdf :
<RRSAgent> ACTION: David - Make sure agenda is ready ahead of time and organsie the remote participation links [1]
<RRSAgent> recorded in https://www.w3.org/2023/08/09-webdriver-irc#T16-11-01
<RRSAgent> ACTION: Orkon - Collect these properties needed and put it in the issue with use cases of how people would use it [2]
<jgraham> zakim, bye
<Zakim> leaving. As of this point the attendees have been AutomatedTester, JimEvans, orkon, mathiasbynens, jgraham, jdescottes, sasha, whimboo, lightning00blade, simonstewart, jrandolf,
<RRSAgent> recorded in https://www.w3.org/2023/08/09-webdriver-irc#T16-45-35
<Zakim> ... gsnedders, cb

[OrKoN]

Option #1 sounds good to me.

[OrKoN]

Option #2 would require some implementation effort on our side but if there is a use case that is currently not covered, it sounds good too.

[OrKoN]

speaking with my selenium hat on I think having a single event type is much easier DX for our users

sounds like a good argument for the option #1

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Session History.

The full IRC log of that discussion

<AutomatedTester> Topic: Session History
<jgraham> github: https://github.com/w3c/webdriver-bidi/issues/502
<AutomatedTester> jgraham: There are 2 questions here. Currently with navigation events we have an event when fragment is navigated but not when there is popstate
<AutomatedTester> ... we could create an event when navigating the history even if it doesn't change url
<shs96c> Classic has https://w3c.github.io/webdriver/#back
<shs96c> q+
<AutomatedTester> ... do we want to be more in line with the navigation API or ...?
<AutomatedTester> ack next
<orkon> q+
<AutomatedTester> shs96c: do we know why puppeteer exposed this in the first place? Was this because its a devtools protocol or was it a conscious decision?
<AutomatedTester> ack next
<AutomatedTester> orkon: it would be better to follow the fragment events and happy to add a new event. For the history of puppeteer we allow people to move back/forward. but we wanted to expose the everything for us to get a larger and more flexible use cases
<AutomatedTester> shs96c: this is why I was wondering how widely used it is?
<jgraham> https://developer.mozilla.org/en-US/docs/Web/API/Navigation_API is the Web Navigation API
<AutomatedTester> orkon: there is a puppeteer use case that allows people <missed something about CDP>
<AutomatedTester> shs96c: forward and back is the most important but getting the complete history is lower priority
<AutomatedTester> orkon: it's definitely harder expose all history across all UA
<AutomatedTester> s/orkon/jgraham
<shs96c> @AutomatedTester: We also need a mechanism to get the current URL
<AutomatedTester> jgraham: The web also has the navigation API (shared)
<AutomatedTester> s/<missed something about CDP>/We also need a mechanism to get the current URL
<AutomatedTester> orkon: you can also inspect history and then decide what to do based on it's content
<AutomatedTester> jgraham: So we need to make sure that we have back/forward. There is support for event when there is a navigate happens
<AutomatedTester> ... and exposing session is what people would like but more advanced used cases are lower priority
<orkon> agreed
<AutomatedTester> q?

[jrandolf]

I'd suggest renaming the fragmentNavigated event to something along the lines of sameDocumentNavigated and doing (1). If the use-case arises that we need to separate history and fragment navigation. We can add a type to the navigation.

The exact location we would add this renamed event would be in https://html.spec.whatwg.org/#finalize-a-same-document-navigation

[whimboo]

Removing or renaming an existing API disrupts our backward compatibility model with WebDriver. If we intend to introduce a new name such as sameDocumentNavigated, we may need to retain frameNavigated for the time being. We could consider marking it as deprecated and potentially remove it later once we are confident that clients have been updated?