Extend existing roadmap

[sadym-chromium]

As we are quite close to specify all the scenarios from the roadmap, we have to extend it. This are scenarios we think makes sense to work on:

1. Device emulation: Extend roadmap: device emulation #420
2. Sandbox session: Extend roadmap: sandbox mode #422
3. bfcache/pre-rendering Can it be tested via network events?
4. Support web extensions: Extend roadmap: web extensions #421)
5. Support workers Can it be tested via network interception?
6. 2FA subset of HTTP authentication
7. Cookies: Extend roadmap: cookies #423

Anything else we should consider adding there?

[jgraham]

Would be nice to get input here from people using the protocol in the wild rather than just guessing. Obviously @mathiasbynens and the other Puppeteer people are good candidates, but @shs96c @jimevans and others from Selenium should pitch in, as well as other users like @CanadaHonk.

From a spec point of view I think workers are already supported; obviously implementation wise it's a bit different.

I agree that various kinds of device emulation and overrides (media queries, timezone, etc.) seem like obvious next steps, because I understand that those are widely used in existing clients. I think there are also a couple of more basic things missing from the existing roadmap:

• Sizing browser windows
• Cookies

Also for "incognito" mode, I think we need some clear thought around requirements. Is it just about opening a new incognito window? Firefox probably wants to also be able to expose containers, since they can provide storage isolation between different tests.

[CanadaHonk]

Personally, #157 is a major blocker as otherwise there is no (easy) way to have bidirectional communication between a client and a page. Also #119 seems like something which might be often used / handy.

[OrKoN]

Cookies (reading/writing) are also important for Puppeteer. From Puppeteer perspective changing the viewport size (part of the device emulation) is more important than sizing windows (which I think we don't even support). Here is the list of all capabilities Puppeteer needs based on our test suite: https://gist.github.com/OrKoN/0c198de4089e8668a48746b223a37d8d

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Extend the roadmap.

The full IRC log of that discussion

<jgraham> Topic: Extend the roadmap
<jgraham> Github: https://github.com//issues/403
<patrickangle_> q+
<jgraham> sadym: We're almost finished speccing the items on the existing roadmap. This issue is for prioritising the next list of things that we should add to BiDi, please take a look.
<jgraham> ack patrickangle_
<jgraham> patrickangle_: With some of these it's unclear what the scope is. e.g. what does device emulation encompass. I'd be interesting in seeing the broader goals and the specific use cases that we're trying to acomplish.
<jgraham> sadym: Like e2e scenarios?
<simons> q+
<jgraham> patrickangle_: Yes, some of them are very broad areas, so getting more clarity would help.
<jgraham> ack simons
<jgraham> simons: The obvious things are figuring out the gaps between classic and bidi so we can reformulate classic on top of bidi.
<jgraham> jgraham: Other specs are also extending webdriver classic e.g. HTML, permissions. If we want to e.g. run wpt on top of BiDi we need to figure out a plan to convert those endpoints into bidi.
<jgraham> q?
<JimEvans> q+
<JimEvans> q-
<jgraham> RRSAgent: make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2023/04/12-webdriver-minutes.html jgraham
<jgraham> RRSAgent: stop logging
<RRSAgent> I'm logging. I don't understand 'stop logging', jgraham. Try /msg RRSAgent help
<jgraham> RRSAgent: stop
<jgraham> JimEvans: Sorry, didn't see you add yourself to the queue at the end there
<JimEvans> jgraham (IRC): In case you've not seen it, I'd love to get some attention on https://github.com//issues/396
<JimEvans> And no worries.
<jgraham> RRSAgent: bye
<RRSAgent> I see no action items
<jgraham> Zakim, bye
<Zakim> leaving. As of this point the attendees have been whimboo, JimEvans, jdescottes, orkon, jgraham, simons, sasha, sadym, patrickangle_
<jgraham1> Jim Evans: Yes, I meant to deal with that today and ended up looking at `browser.close` instead.
<jgraham1> I haven't looked in detail, but if the issue's accurate it's a pure oversight in the CDDL.
<JimEvans> Was trying to use the experimental support for Input in Firefox over the weekend, and hit that as a snag.
<JimEvans> (geckodriver expects the �id� property in the bidi input payload, because it's present in classic)
<JimEvans> Easy enough to correct on the client side (just add the id property), but the spec does need to be updated.
<JimEvans> If I were to call the `script.callFunction` command with a `functionDefinition` property of `"() => { return { \"stringProperty\": \"stringValue\", \"map\": { \"numberProperty\": 3, \"anArray\": [ true, false ] } }; }"` what would be the expected result? I'm particularly interested in the return value of the `map` property in the return payload.

[jimevans]

Window sizing/positioning is important for Selenium, as is cookie manipulation (the latter is more important to implement first than the former). These are the biggest things missing from the roadmap as it currently stands from the Selenium perspective.

It would probably be useful to have some primitives for node inspection for things like "is this element obscured by another element," and "is this element currently in the view port, and in scrolled into the visible portion of any/all enclosing elements' overflow areas." Those are challenging to create pure JavaScript/DOM implementations for. Note that I am expressly not asking for an "is node visible" primitive, as useful as that would be, because there's no easy way to come to a consensus on what "visible" means in spec language. A mechanism for determining when animations of a node are completed would be a significant win for BiDi-based clients.

I want to second the suggestion for expanding taking of screenshots to include both full screen, and cropped to a single node.

History traversal is important for API completeness, and there's an extant PR, but it needs work to integrate with changed upstream specs.

[christian-bromann]

I would love to see more standardisation around browser specific capabilities to help spawn a browser in a certain state. There is already a lot of alignment among Firefox and Chrome while having a lot of unknowns in Safari. However while specifics can be up to the browser implementation, it seems we can agree on the following things to be very commonly used:

• binary path
• args: command line arguments to start browser
• prefs: browser specific configurations
• loading of web extensions
• log level

What I don't know is if that is something that can be specified in this spec. However it seems we kind of already have agreed on them so why not removing the remaining ambiguities.

[ollie-iterators]

Another suggestion could be about helping the user force element states for an element that does not depend on the CDP area as mentioned in this Issue: #249

[etanol]

#427 proposes a very interesting feature to reliably write file download tests.

On the other hand I haven't found anything in this repository about file upload. This is something that has been left behind in W3C WebDriver specification and it used to work before W3C. For example, chromedriver can attach files to forms over the wire; or in Selenium terms, the local file detector works.

But this feature is not covered by the W3C WebDriver standard and it's not clear if it will be.

WebDriver BiDi should also cover file download/upload features. After all, they can be important features to test in web applications.

[foolip]

I would love to see more standardisation around browser specific capabilities to help spawn a browser in a certain state. There is already a lot of alignment among Firefox and Chrome while having a lot of unknowns in Safari. However while specifics can be up to the browser implementation, it seems we can agree on the following things to be very commonly used:

• binary path
• args: command line arguments to start browser
• prefs: browser specific configurations

@christian-bromann these have to do with launching the browser, which BiDi doesn't do itself, it's part of https://w3c.github.io/webdriver/. There's an example in https://w3c.github.io/webdriver/#example-5 for browser specific configuration, is the request to standardize that?

[foolip]

log level

@christian-bromann can you elaborate on this? Is it the browser's internal logging?

[foolip]

@etanol can you elaborate a bit on the upload scenario? Do you mean using WebDriver to select a file for <input type=file>? Or do you want something like network intercept and the ability to replace the data the browser would otherwise send? I'm not familiar with the chromedriver feature you're referring to.

[foolip]

@sadym-chromium found https://www.selenium.dev/documentation/webdriver/elements/file_upload/ which is how file upload works in Selenium. Send the name of the file to the <input type=file> as keyboard input :)