Closed Bug 1730642 Opened 3 years ago Closed 3 years ago

Implement basic support for "browsingContext.navigate" command

Categories

(Remote Protocol :: WebDriver BiDi, task, P2)

task
Points:
13

Tracking

(firefox101 fixed)

RESOLVED FIXED
101 Branch
Tracking Status
firefox101 --- fixed

People

(Reporter: whimboo, Assigned: jdescottes)

References

(Blocks 3 open bugs, )

Details

(Whiteboard: [bidi-m3-mvp], [wptsync upstream])

Attachments

(5 files, 5 obsolete files)

(deleted), text/x-phabricator-request
Details
(deleted), text/x-phabricator-request
Details
(deleted), text/x-phabricator-request
Details
(deleted), text/x-phabricator-request
Details
(deleted), text/x-phabricator-request
Details

For our milestone 2 we want to have a basic implementation of this command, which allows a navigation to simple pages. It should also emit appropriate page load events, and as such handle the ReadinessState argument correctly.

Do we want / have to trigger the navigation via fetch for the initial implementation? Might be needed when we have to return the request in the response. What else could be simplified for now so that we have the basics working? We will discuss in the triage meeting today.

Points: --- → 13
Priority: -- → P2

Having a navigation id for the initial basic implementation would be great, but as discussed we are not sure what to base it on. In CDP we make use of the httpChannel.channelId which comes via the http-on-modify-request observer notification. But for WebDriver BiDi we do not have network events defined yet, and as such shouldn't get started to implement these at this time. Julian mentioned that the innerWindowId might work here, and he is going to check what's in use in DevTools.

Also if we have to add more bugs from the contingency list we might have to reduce the scope of this bug, and possibly not add the navigation id. In such a case we might have to wait for the load event to ensure the navigation has been done. That way we could already make use of it in BiDi tests and not have to fallback to WebDriver HTTP for navigation.

Flags: needinfo?(jdescottes)

innerWindowId will be set too late and might also be set to an intermediary value for a temporary about:blank page. It sounds like using a channel id is the best identifier we can use.

Rather than blocking this on the support for "bidi network events", why not just add a network observer helper and only use it for the purpose of getting a navigation id?

Flags: needinfo?(jdescottes)

After discussing a bit with Alex, while the channelId is probably the first ID which will be generated for a navigation, it might be worth investigating the WebProgressListener. We should get notified even earlier about the navigation there, and this should provide a more comprehensive view of the navigation. The problem is that it doesn't really expose any id, but we might be able to create one based on it. Will make a few tests and report back.

Flags: needinfo?(jdescottes)
Priority: P2 → P3

Will come back to this when re-prioritised

Flags: needinfo?(jdescottes)
Priority: P3 → --
Whiteboard: [bidi-m2-mvp] → [bidi-m3-mvp]
Blocks: 1742980
Depends on: 1664165

So in bug 1664165 we will make use of a webProgress listener in Marionette which then can be used as a shared module with WebDriver BiDi. We decided this way because there are already a lot of navigation tests to use for proving the stability of the code change.

This bug only covers the navigation and doesn't care about any WebDriver BiDi navigation event.

Priority: -- → P2
Depends on: 1751856
Depends on: 1756809
Assignee: nobody → jdescottes
Status: NEW → ASSIGNED
No longer depends on: 1664165

Hi Olli,

For this bug, we need to create a "navigation id" that should remain valid for a complete navigation. Initially we imagined using a channelId from the webProgress' request, either webProgress.documentRequest or the request parameter passed to onStateChange callbacks.

But as you wrote on https://phabricator.services.mozilla.com/D137212#4467500 it should be quite obvious the request isn't real, since it isn't nsIChannel and can't be QI'ed to such. And indeed I cannot query interface those to Ci.nsIIdentChannel and therefore I can't get a channelId. I thought the comment only applied to documentRequest, but I don't have better success with the request params for onStateChange. And reading BrowsingContextWebProgress.cpp, they should be the same object anyway.

So my first question: is there any way to get the channelId from a WebProgress(Listener)?

Taking a step back, I imagine "complete navigation" and "navigate id" are not clearly defined. Here it corresponds to the "navigation id" defined at https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigation-id. Maybe channelId is not a good fit for this?

Flags: needinfo?(bugs)

On Matrix I was wondering if BrowsingContext's CurrentLoadIdentifier could be used here. It isn't quite clear to me for what all the identifier is needed.

Flags: needinfo?(bugs)

Depends on D141585

Depends on D141585

Depends on D141899

Attachment #9268966 - Attachment is obsolete: true
Attachment #9269131 - Attachment is obsolete: true
Attachment #9269130 - Attachment is obsolete: true
Attachment #9268975 - Attachment is obsolete: true
Blocks: 1763108
Blocks: 1763109
Blocks: 1763137
Attachment #9269453 - Attachment is obsolete: true
Pushed by jdescottes@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b44490766902 [remote] Emit internal MessageHandler events with their original name r=webdriver-reviewers,whimboo https://hg.mozilla.org/integration/autoland/rev/ea90b69932c6 [remote] Extract internal event logic to a dedicated class r=webdriver-reviewers,whimboo https://hg.mozilla.org/integration/autoland/rev/cdb26d86df58 [webdriver-bidi] Implement a basic browsingContext.navigate command r=webdriver-reviewers,whimboo https://hg.mozilla.org/integration/autoland/rev/c91aaf83fbe4 [wdspec] Add browsing context navigate command to browsing context module r=webdriver-reviewers,whimboo https://hg.mozilla.org/integration/autoland/rev/dcc7ccedfd3b [wdspec] Added web-platform tests for browsingContext.navigate command r=webdriver-reviewers,whimboo
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/33550 for changes under testing/web-platform/tests
Whiteboard: [bidi-m3-mvp] → [bidi-m3-mvp], [wptsync upstream]
Upstream PR merged by moz-wptsync-bot
Regressions: 1763692
Blocks: 1766043
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: