-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a browsingContext.traverseHistory command #109
base: main
Are you sure you want to change the base?
Conversation
This depends on #107 plus some additional changes to the HTML spec that I haven't created a PR for yet. |
index.bs
Outdated
|
||
BrowsingContextReloadParameters = { | ||
context: BrowsingContext, | ||
delta: int, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using a delta to define the number of history entries to move back or forward means that we also need an API to actually retrieve the maximum amount of entries.
Maybe pages might also be interested in to go back/forward to a specific URL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't mean we need that if there aren't use cases for it. HTTP-based WebDriver just has /back
and /forward
. Puppeteer has goBack and goForward
, which PlayWright seems to have kept unchanged. Cypress has go which takes a delta. I can't see any of them having an API to go back/forward to a specific URL or to get a the size of the session history.
I think if those use cases come up later we'd be better off adding an API that returns a list of session history entries, like CDP. Such an PI seems useful for testing the platform itself, but it's hard to argue it's part of the MVP for replacing existing automation tools given none of them provide it.
index.bs
Outdated
parameters| if present, or "<code>none</code>" otherwise. | ||
|
||
1. Let |navigate status| be the result of running the [=traverse the history | ||
by a delta steps=] given |delta|, and |context|. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What should happen if delta
is outside of the maximum available pages in the history? Should it be silently ignored as in this case, or a specific error raised?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There will be an error although at this point there's a lot of unknown error
. I (or someone else!) need to put some time into rewriting the error codes for BiDi.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jgraham would you mind filing a new issue for that with details? Would be good to keep that on our radar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#112 covers this.
index.bs
Outdated
1. If |event received| is "<code>navigation failed</code>" | ||
return [=error=] with [=error code=] [=unknown error=]. | ||
|
||
1. If |event received| is "<code>page show</code>", let |persisted| be true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be set to the value of the persisted
property of pageshow
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not as currently written because the hook in the HTML spec (which needs a seperate PR) is only invoked if the page came out of the bfcache, not if the page was loaded normally. Therefore persisted
is always true in this case. If we change things so there's a BiDi context.pageShow
event then we'll need to set the persisted property in the hook and reflect that here.
index.bs
Outdated
The <dfn export>WebDriver-BiDi page show</dfn> steps given <var | ||
ignore>context</var> and |navigation status| are: | ||
|
||
Issue: Do we want to expose a `browsingContext.pageShow event? In that case we'd |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't that what we will do for navigation anyway when no wait parameter has been given and the command returns immediately?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The question is whether we want a specific event for it so that clients can wait for pageShow even if it's triggered by something other than a navigation command. I'm inclined to think it would probably be a good idea, given pageshow/pagehide are typically the most reliable things to use in the face of bfcache. I don't quite know if it's covered by Page.lifecycleEvent
in CDP since the docs don't mention when the events are actually emitted.
The Browser Testing and Tools Working Group just discussed The full IRC log of that discussion<jgraham> topic: context.traverseHistory<AutomatedTester> github: https://github.com//pull/109 <AutomatedTester> jgraham (IRC): The third change is moving through history <AutomatedTester> ... I have a draft PR for the html spec changes we need <AutomatedTester> ... the model here is that you can move via a delta <AutomatedTester> ... this is different to CDP but the clients do this <AutomatedTester> ... and it is closer to what cypress does as other tools just have back/forward <AutomatedTester> ... and since there are things in the bfcache there might not be events that are returned to the user <AutomatedTester> q? |
39072b4
to
3832f2a
Compare
WebDriver BiDi wants to invoke the 'traverse the history by a delta` algorithm, and get a callback whenever the algoritihm has run to completion, either by failing or by the navigation or state restoration completing. w3c/webdriver-bidi#109 is the WebDriver BiDi side of this change.
whatwg/html#6921 for the HTML side of this change. |
9771433
to
ea398f9
Compare
WebDriver BiDi wants to invoke the 'traverse the history by a delta` algorithm, and get a callback whenever the algoritihm has run to completion, either by failing or by the navigation or state restoration completing. w3c/webdriver-bidi#109 is the WebDriver BiDi side of this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Just left some minor comments.
index.bs
Outdated
1. Assert: |navigate status|'s status is "<code>pending</code>" and | ||
|navigation id| is not null. | ||
|
||
1. If |wait condition| is "<code>none</code>": |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wait condition
needs to be passed as a parameter to this algorithm.
index.bs
Outdated
<code>url</code> field set to the result of the [=URL serializer=] given | ||
|navigate status|'s url. | ||
|
||
1. Return [=success=] with data |body|, and then run the following steps [=in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will the "in parallel" here be replaced with "queue a task" after #115?
index.bs
Outdated
1. Return [=success=] with data |body|, and then run the following steps [=in | ||
parallel=]: | ||
|
||
1. Run the [=WebDriver-BiDi fragment navigated=] steps given |context| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Matching whatwg/html#6921:
1. Run the [=WebDriver-BiDi fragment navigated=] steps given |context| | |
1. Run the [=WebDriver BiDi fragment navigated=] steps given |context| |
index.bs
Outdated
1. Return [=success=] with data |body|, and then run the following steps [=in | ||
parallel=]: | ||
|
||
1. Run the [=WebDriver-BiDi navigation started=] steps given |context| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is all a bit hard to grasp initially, so to spell out what's going on with all the returning and in parallel: it's to ensure that the command response comes before any events. The "WebDriver BiDi navigation started" algorithm just emits the event, it doesn't call into HTML or anything else.
Also good ol' hyphen suggestion:
1. Run the [=WebDriver-BiDi navigation started=] steps given |context| | |
1. Run the [=WebDriver BiDi navigation started=] steps given |context| |
index.bs
Outdated
1. Run the [=WebDriver-BiDi fragment navigated=] steps given |context| | ||
and |navigate status| | ||
|
||
Note: this is the case if the navigation only caused the fragment to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I follow what's going on here. This happens unconditionally, but history traversal isn't always a fragment navigation. Does this perfectly and intricately balance the now conditional invocation of "WebDriver BiDi fragment navigated" on the HTML side that I wondered about in whatwg/html#6921 (comment)?
Also, capitalization nit since the note is forever:
Note: this is the case if the navigation only caused the fragment to | |
Note: This is the case if the navigation only caused the fragment to |
index.bs
Outdated
1. Run the [=WebDriver-BiDi navigation started=] steps given |context| | ||
and |navigate status| | ||
|
||
Note: this event was previously suppressed to ensure that it would come |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Closing the door to my initial reading that this is about a previous state of the spec:
Note: this event was previously suppressed to ensure that it would come | |
Note: This event was previously suppressed to ensure that it comes |
index.bs
Outdated
after the command response in the case that |wait condition| is | ||
"<code>none</code>". | ||
|
||
Issue: Replace this suppression mechanism with an event queue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes please 👍
index.bs
Outdated
|
||
</div> | ||
|
||
#### The browsingContext.reload Command #### {#command-browsingContext-reload} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the browsingContext.reload addition doing here? I assume it'll go away with a rebase and will ignore here.
8e3c428
to
c75510b
Compare
WebDriver BiDi wants to invoke the 'traverse the history by a delta` algorithm, and get a callback whenever the algoritihm has run to completion, either by failing or by the navigation or state restoration completing. w3c/webdriver-bidi#109 is the WebDriver BiDi side of this change.
Hi @jgraham. I just stumbled over this PR and wonder what's actually left to do here. There are some review comments you might wanna have a look at. |
Yeah, this got dropped a bit. The main thing left to do is actually land the HTML side patch. |
@jgraham I've merged to resolve conflicts, but further changes are still needed. The "child browsing contexts" concept is no longer in HTML, and perhaps other things. |
This traverses the history by a specified `delta` (e.g. +1 for forward, or -1 for back). Like other navigation commands the `wait` parameter controls whether to return as soon as the history traversal starts, or wait for a specified level of completeness. Mush like other navigation commands, history traversal is tracked with a unique navigation id. Typically history traversal results in a navigation, but in the case of the history entry being in the bfcache, no navigation is necessary. In this case any non-"none" value for wait will return once the `pageshow` event is fired, and the `persisted` attribute of the return value is set to `true`. This model differs somewhat from the CDP model where one navigates to an explicit history entry and failure is only possible if the entry id is invalid. But back/forwward only seems closer to the use cases we have, and allowing events to be traced to a specific traversal seems consistent with the way we handle other navigation-related events.
acf3b05
to
58fccb9
Compare
browsingContext.SetViewport | ||
browsingContext.TraverseHistory |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
browsingContext.SetViewport | |
browsingContext.TraverseHistory | |
browsingContext.SetViewport // | |
browsingContext.TraverseHistory |
@@ -1864,6 +1866,7 @@ BrowsingContextResult = ( | |||
browsingContext.GetTreeResult // | |||
browsingContext.NavigateResult // | |||
browsingContext.PrintResult |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
browsingContext.PrintResult | |
browsingContext.PrintResult // |
|
||
browsingContext.TraverseHistoryParameters = { | ||
context: browsingContext.BrowsingContext, | ||
delta: int, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
delta: int, | |
delta: js-int, |
?persisted: bool | ||
url: text, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
?persisted: bool | |
url: text, | |
url: text, | |
? persisted: bool |
1. Let |browsing context| be the result of [=trying=] to [=get a browsing context=] | ||
with |command parameters|["<code>context</code>"]|. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets stay in sync with the other commands.
1. Let |browsing context| be the result of [=trying=] to [=get a browsing context=] | |
with |command parameters|["<code>context</code>"]|. | |
1. Let |context id| be the value of the <code>context</code> field of | |
|command parameters|. | |
1. Let |context| be the result of [=trying=] to [=get a browsing context=] | |
with |context id|. | |
condition| be |command parameters|["<code>wait</code>"]. Otherwise let |wait | ||
condition| be "<code>none</code>". | ||
|
||
1. Let |navigation id| be the string representation of a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we maybe integrate all the following in await a navigation
? We may be able to pass in another argument like delta
to differentiate between a normal navigation and a history traversal. That way we wouldn't have to duplicate that much code.
|
||
Issue: Do we want to expose a `browsingContext.pageShow event? In that case we'd | ||
need to call this whenever `pageshow` is going to be emitted, not just on | ||
bfcache restore, and also add the persisted status to the data. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@OrKoN would that be beneficial / helpful for Puppeteer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might be but we currently do not support bfcache in Puppeteer. I think it's related to the prerendering topic too #321 So far there is nothing in WebDriver BiDi that would cover navigations that are bfcache restore/prerendering activation. I think we will need to come up with something before restoring would result in a different browsing context becoming the primary context in a tab.
Superseded by #584? |
Not quite, let's move this one back to draft and it can cover the addition of |
This traverses the history by a specified
delta
(e.g. +1 for forward,or -1 for back). Like other navigation commands the
wait
parametercontrols whether to return as soon as the history traversal starts, or
wait for a specified level of completeness.
Mush like other navigation commands, history traversal is tracked with
a unique navigation id.
Typically history traversal results in a navigation, but in the case
of the history entry being in the bfcache, no navigation is
necessary. In this case any non-"none" value for wait will return once
the
pageshow
event is fired, and thepersisted
attribute of thereturn value is set to
true
.This model differs somewhat from the CDP model where one navigates to
an explicit history entry and failure is only possible if the entry id
is invalid. But back/forwward only seems closer to the use cases we
have, and allowing events to be traced to a specific traversal seems
consistent with the way we handle other navigation-related events.
Preview | Diff
Preview | Diff