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 :)

[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/.

I was assuming that capability extensions defined in WebDriver would apply the same way to Bidi and its session.New command. Maybe I am confusing something here 🤔

There's an example in https://w3c.github.io/webdriver/#example-5 for browser specific configuration, is the request to standardize that?

Yes, it would be nice if browser binary launch args can be passed in a standardised way to the driver. With prefs I am not sure if this can be done as I am not aware how browser preferences are managed cross browser. However it would be nice to have some sort of control over that too.

can you elaborate on this? Is it the browser's internal logging?

Yes, but in hindsight I am not sure anymore what valuable use cases I could get out of this. The only one I could thing of is to provide more information when browser crash.

[jgraham]

I was assuming that capability extensions defined in WebDriver would apply the same way to Bidi and its session.New command

I think that's "true", but there's a bit of confusion from the fact that WebDriver conflates two things:

• A program that can launch the browser and configure its initial settings.
• Remote control of the browser itself.

For WebDriver classic that makes a certain amount of sense, and the *driver binaries provide the intermediate layer that handles process control (and also in practice convert the protocol into some internal format).

For BiDi there are more use cases that work without assuming the protocol needs to launch a browser instance (e.g. a profiling application that uses network events to log the traffic of a browser instance that's separately controlled by some other automation tool), and other protocols like CDP don't assume that the protocol itself is launching/configuring the browser (which obviously doesn't make sense for devtools).

I've filed #447 with some more thoughts about initial configuration.

[etanol]

@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.

I'm refering to the former. The W3C standard does not include mechanisms to attach files to web forms over the wire (and w3c/webdriver#1355 doesn't bring much hope). You can remotely fill a file form file with the file path, but it will only work if the file is co-located in the same filesystem as the browser.

Before the W3C specification, some drivers were capable of receiving the contents of a file to be attached in a form; from the client (i.e. the process executing the end-to-end tests). This is still possible in chromedriver as a non-standard endpoint. And the Selenium Java client also carries over some baggage from the past (see the implementation, exposed as the LocalFileDetector).

In the face of browser farm providers, managing to place a file in the same filesystem where the browser reads from, is almost the same kind of problem that test writers face when having to wait for a file to be downloaded completely.

Hence my reference to #427: If there are improvement plans for file downloads, please don't forget about file uploads.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Roadmap.

The full IRC log of that discussion

<AutomatedTester> Topic: Roadmap
<AutomatedTester> github: https://github.com//issues/403
<AutomatedTester> mathiasbynens (IRC): I will get us started on this
<AutomatedTester> ... THere are some draft PRs against the spec of things that need working on
<jgraham_> q+
<AutomatedTester> ... we have some good use cases of what people want
<AutomatedTester> q?
<AutomatedTester> ack next
<simons> q+
<AutomatedTester> jgraham: one weakness of what we ahve done in the past is that we have looked at abstract use cases and not always the client use cases
<AutomatedTester> ... e.g. setEmulation is needed for puppeteer to work and isn't on our roadmap
<AutomatedTester> ... so I think we need to focus on what we can do to get clients using bidi in the short term
<AutomatedTester> ack next
<AutomatedTester> simons: one thing that we should have is to have reformulating webdriver classic on top of webdriver bidi
<whimboo> q+
<AutomatedTester> ... but figuring out what is missing would be a rich seam of work for us moving forward
<mathiasbynens> q+
<AutomatedTester> ack next
<jgraham_> q+
<AutomatedTester> whimboo: the last time we did this we started with Selenium and puppeteer needs and work out the priority from there
<AutomatedTester> ack next
<AutomatedTester> mathiasbynens (IRC): the puppeteer needs are documented in this thread here. The top of the issue has things in the order of what we need
<AutomatedTester> simons: could you reformat what you're saying into a use case
<AutomatedTester> ... the use case is mostly for those writing clients and not the end user writing tests
<AutomatedTester> ... in terms of missing functionality, I don't know what's missing but we should try figure out if there are things
<AutomatedTester> mathiasbynens (IRC): but that makes a new audience moving forward
<AutomatedTester> simons: yes I agree
<AutomatedTester> jgraham_ (IRC): the classic spec has a lot of good use cases that people need are there
<AutomatedTester> ... and there is a 2nd level of detail and is lower priority is the ability to make chromedriver use bidi on it's own
<AutomatedTester> ... and I do think that "it must be an end user use case" is ok but I think we can do better
<AutomatedTester> ... I think that making the clients working is a much better approach
<AutomatedTester> ... the priority here is to make sure that we can work and not all use cases come into it. e.g. setEmulation
<AutomatedTester> ack next
<AutomatedTester> mathiasbynens (IRC): should we add simons item on classic reformulation?
<AutomatedTester> jgraham_ (IRC): perhaps but maybe that should be more of a process
<gsnedders> q+
<AutomatedTester> ... I think we should use this and perhaps spreadsheets
<whimboo> https://docs.google.com/spreadsheets/d/1fmPugULnRlsuUGHLnjTdlUWU01X4kkVfrLjj96w_Tcc/edit?usp=sharing
<AutomatedTester> ack next
<AutomatedTester> Sam Sneddon [:gsnedders]: when we are working on things defined on webdriver classic are we discussing the proper spec or the extension points to that spec in other specifications
<AutomatedTester> jgraham_ (IRC): yes
<AutomatedTester> ... some of it is purely browser testing rather than web app testing but I do believe that it is in scope
<gsnedders> s/or the extension points/or also the extension points/
<jgraham> https://docs.google.com/spreadsheets/d/1Cg3rifrBZClIitU3aFW_WDv64gY3ge8xPtN-HE1qzrY/edit#gid=0
<sadym> q+
<gsnedders> whimboo: you changed "Print screenshot" to "Capture screenshot", but that has different sets of existing implementations in Classic, so we probably need to split them?
<jgraham_> Both print and capture are already in BiDi, so if it's specific subfeatures we should call them out
<jgraham_> Aren't atoms already handled by preload scripts?
<AutomatedTester> ack next
<cb> WebdriverIO has a lot of Appium users that run mobile web tests in emu/simulators
<gsnedders> jgraham_: Ah, I missed them being there 🙃
<AutomatedTester> mathiasbynens (IRC): Why don't Selenium/WebDriverIO need device emulations?
<AutomatedTester> automatedtester: Selenium works with those mobile browsers either on real devices or via emulators/simulators?
<AutomatedTester> jgraham_ (IRC): are we talking about viewport or device px or?... I have added a new column to make sure that we have the same understanding of terms
<orkon> q+
<AutomatedTester> AlexRudenko: for device emulation the minimum is viewport shaping
<AutomatedTester> ... at the minimum.
<AutomatedTester> ... users struggle with getting the correct window size becauae of the browser chrome impacting the window size
<AutomatedTester> ... in puppeteer it is set as a initial capability
<AutomatedTester> ... window size can impact all tabs in the main window
<AutomatedTester> ... there is a spec proposal
<AutomatedTester> ack next
<orkon> q+
<AutomatedTester> ack next
<AutomatedTester> AlexRudenko: it allows you to make a "temp profile"
<AutomatedTester> ... for sandbox. The issue is here is to try help handling the browser start up and creates an "private/incognito" tab which is much faster than restarting the browser
<AutomatedTester> jgraham: this could be interesting to spec as there are no standard way of describing items between browsers. this might not map to profiles... e.g. containers in firefox might be the same here but we don't know
<AutomatedTester> sadym (IRC): webextensions: what we suggest we add the ability to install extensions and access background pages
<AutomatedTester> jgraham_ (IRC): I suggest we split this into 2 tasks
<AutomatedTester> ... loading is 1 and what people might do
<AutomatedTester> ... and debugging is a very different thing
<whimboo> q+
<AutomatedTester> ack next
<AutomatedTester> whimboo: do we also need uninstall and enable/disable?
<simons> q+
<AutomatedTester> ack next
<AutomatedTester> simons: we definitely install/uninstall as a priority for this item. Enable/disable are nice to haves
<AutomatedTester> AlexRudenko: puppeteer only allows the installation of extesnions
<AutomatedTester> sadym (IRC): get/set/delete of cookies for a specific origin
<AutomatedTester> automatedtester: do we want access to the cookie jar from outside the origin?
<AutomatedTester> jgraham_ (IRC): yes, we need to rethink this as cookies have grown since we did this originally
<AutomatedTester> whimboo: window manipulation: this is similar to device emulation is that we need to manipulate the browser window
<AutomatedTester> ... and then we have window manager impacting this
<AutomatedTester> ... i'm not sure if we should split this between resizing and window movement
<AutomatedTester> q?
<AutomatedTester> ... I am not sure how useful maximise and minimise on the window
<AutomatedTester> whimboo: in bidi we can run any commands in any context
<AutomatedTester> ... but there are some commands that need that context to be in focus
<AutomatedTester> ... e.g. puppeteer needs it for screenshots
<gsnedders> q+
<AutomatedTester> ... and browsers may throtlle what is happening in non-focused browsers like firefox does
<AutomatedTester> ack next
<AutomatedTester> Sam Sneddon [:gsnedders]: related to throttling, there are browsers following OS "low power modes" which can impact the frequency of different events
<whimboo> q+
<AutomatedTester> ... this is kinda detached to focus but has similar impacts to being in out of focus
<AutomatedTester> whimboo: Firefox doesn't have this impact
<AutomatedTester> mathiasbynens (IRC): Sam Sneddon [:gsnedders] should we add this to the queue?
<AutomatedTester> Sam Sneddon [:gsnedders]: maybe but I'm not sure of the proirity here
<AutomatedTester> whimboo: we could maybe add this a capability
<AutomatedTester> Sam Sneddon [:gsnedders]: more importantly going into lower power mode may break websites so we want to be able to do that somewhere
<AutomatedTester> simons: Framehandling: this boils down to getting a browsing context of a frame. Executing JS might not always work
<AutomatedTester> ... t
<AutomatedTester> ... the classic has commands to do this and would be good to make work
<JimEvans> q+
<AutomatedTester> jgraham_ (IRC): in bidi you can do this via executeScript
<AutomatedTester> ... but there might be the missing part of returning an iframe should return the context. I believe ther eis an open issue for that
<sadym> q+
<AutomatedTester> ack next
<AutomatedTester> ack next
<AutomatedTester> Jim Evans: there is some functionality from the browsing context as that has child browsing context shared
<AutomatedTester> simons: as long as we can formulate classic over bidi here then we should be fine
<AutomatedTester> whimboo: clients should be able to track all of this
<AutomatedTester> ack next
<AutomatedTester> sadym (IRC): do we have a use case for the finding a node that could be in an child context?
<AutomatedTester> AlexRudenko: we might have a use case in puppeteer especially around clicks but not sure
<sadym> do we have a use case for the finding a node that is a root for the child context?
<sadym> *specific child node
<AutomatedTester> jgraham: a11y inspection: in classic we have getComputed{Label|role}
<AutomatedTester> ... there are going to be more requests probably from other groups
<AutomatedTester> ... we should at least reimplement classic over bidi here
<AutomatedTester> mathiasbynens (IRC): there is also querying the a11y tree instead of just dumping it
<AutomatedTester> Sam Sneddon [:gsnedders]: There are some investigations into the tree querying by other wg's and that might make it into classic at some point
<gsnedders> s/that might/querying parent/child relationships might/
<gsnedders> RRSAgent (IRC): make minutes
<gsnedders> rrsagent, make log public
<RRSAgent> I have made the request, gsnedders
<gsnedders> rrsagent, draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2023/06/14-webdriver-minutes.html gsnedders
<gsnedders> s/RRSAgent (IRC): make minutes//
<AutomatedTester> simons: Proxy settings: I can see that we are add this and delegate down to new session
<AutomatedTester> whimboo: we don't have wdspec tests atm
<AutomatedTester> simons: Timeouts: we have these in classic but no analogues in bidi yet
<AutomatedTester> jgraham_ (IRC): from my point this is by design as it can be implemented in the spec
<AutomatedTester> simons: not all languages can do this in a sane way
<AutomatedTester> ... and then if you're going across the web might cause other issues
<orkon> q+
<AutomatedTester> unknown: if the person are connecting over long distances and causing issues thats outside scope
<AutomatedTester> simons: not everyone has good UAT systems
<whimboo> q+
<AutomatedTester> unknown: most languages can handle timeouts
<AutomatedTester> simons: a lot of languages can this but then creates situation where we are not the same in all clients
<sadym> q+
<AutomatedTester> simons: we can put it anywhere, in classic we put it the spec as that is where we felt the complexity live
<AutomatedTester> q?
<orkon> q-
<whimboo> q-
<sadym> q-
<AutomatedTester> whimboo: we need to make sure that for timeouts we have all the same items in classic as they have script/navigations etc timeouts
<AutomatedTester> jgraham_ (IRC): file upload: for classic we handle input type=file and we probably need to figure out something similar for bidi
<simons> q+
<AutomatedTester> ... there also may need to handle sending the file to the remote machine to run the file upload
<AutomatedTester> ack next
<AutomatedTester> simons: one small note: for uploading on remote machines an intermediary node should handle that and selenium has prior art for that now
<AutomatedTester> sadym (IRC): element location: is this for find element
<AutomatedTester> jgraham_ (IRC): there are commands for handling the location of the element and we should probably add that to the end
<AutomatedTester> q?
<jrandolf> q+
<AutomatedTester> ack next
<jrandolf> q-
<AutomatedTester> whimboo: isShown: So this is an API to see if an element is visible... but this might also be shared in the atoms line
<AutomatedTester> automatedtester: I think chromedriver uses the atoms here
<AutomatedTester> ... and maybe safari
<AutomatedTester> Sam Sneddon [:gsnedders]: I don't think we do
<AutomatedTester> jgraham_ (IRC): form elements: this is specifically for setting complex form input type e.g. <input type=color>
<AutomatedTester> ... and we don't ahve means to set that
<orkon> q+
<AutomatedTester> ... and I am assuming puppeteer has a way
<AutomatedTester> ack next
<AutomatedTester> orkon: we do this via script execute and set the �value� property
<AutomatedTester> mathiasbynens (IRC): there are ways to do via setting the value property and works for most things
<AutomatedTester> ... but not work everywhere
<AutomatedTester> jrandolf: we might be able to do things with interaction in another way
<AutomatedTester> Sam Sneddon [:gsnedders]: these don't always work on mobile
<gsnedders> s/in another way/with drag and drop/
<gsnedders> s/these don't/drag and drop doesn't/
<AutomatedTester> whimboo: element interaction: this covers all elements
<AutomatedTester> ... we have most of this covered by the user interaction APIs
<AutomatedTester> ... we probably don't want to carry over element send keys from classic
<AutomatedTester> ... and we can remove from this discussion as it's being implemented
<orkon> q+
<orkon> q-
<AutomatedTester> jgraham_ (IRC): browser process info: the request is to have system information being sent over so that we can return PID and system usage info
<AutomatedTester> Jim Evans: geo location: the idea that someone wants to be able to set the browser location different to where they are currently testing
<AutomatedTester> ... e.g. testing differences between US and EU
<AutomatedTester> ... not currently avialble in classic
<AutomatedTester> ... and this also goes for the timezone
<AutomatedTester> mathiasbynens (IRC): yes agreed
<AutomatedTester> ... but this also comes to the idea of permissions for geolocation. We should set the value so the prompt doesn't appear to the user if it also ready set
<AutomatedTester> sadym (IRC): User Agent: If we split it from device emulation then we should need to set the user agent for the given browser context
<AutomatedTester> .. and it is required by puppeteer
<AutomatedTester> jgraham_ (IRC): is getting different to window.navigator.useragent?
<AutomatedTester> AlexRudenko: there can be a need for original user agent vs browsing context user agent
<AutomatedTester> whimboo: locale/lang emulation: it is important to be able to change the locale/language so that the relevent content is sent
<AutomatedTester> ... this is a request from the playwright team
<AutomatedTester> jgraham_ (IRC): history traversal: This is implemented in classic for moving back/forward through pages
<AutomatedTester> jgraham_ (IRC): user gesture during navigation: it's not gesture in the terms of input
<AutomatedTester> AlexRudenko: in script there are reuqests to make sure scripts are available before a page load for gestures
<jgraham_> https://github.com/web-platform-tests/rfcs/pull/128
<AutomatedTester> Sam Sneddon [:gsnedders]: there are things in html for handling some of these cases
<jgraham_> https://github.com/whatwg/html/pull/8609
<sadym> q+
<sadym> q-
<AutomatedTester> whimboo: screenshots; We have basic feature but don't have all of it. e.g. we dont have full screen or element screenshots
<AutomatedTester> jgraham_ (IRC): so lets split this to element and others
<orkon> q+
<sadym> q+
<AutomatedTester> ack next
<sadym> q-
<gsnedders> q+
<AutomatedTester> orkon: I wanted to mention that this could be solved by cropping images
<AutomatedTester> ack next
<AutomatedTester> Sam Sneddon [:gsnedders]: what happens if the element is larger than the viewport
<AutomatedTester> automatedtester: good questions but not part of this question now :)
<AutomatedTester> whimboo: click and wait: this is a feature for classic
<AutomatedTester> ... if you click an element and it has potential for the page to load and capture that it is moving over
<AutomatedTester> ... it's tricky for browsers to do this when it could handle this in the client
<AutomatedTester> sadym (IRC): atoms: we use selenium atoms in chromedriver
<AutomatedTester> ... do we want to be able to handle things purely in browser or do we want to allow the use of atoms for things?
<mathiasbynens> q+
<jgraham_> q+
<AutomatedTester> ack next
<simons> q+
<AutomatedTester> mathiasbynens (IRC): this goes to prioritization and if we can do things simple in the client
<AutomatedTester> ... I think we should unlock more use cases even if the way we do it isn't optimal
<AutomatedTester> ack next
<AutomatedTester> jgraham_ (IRC): the spec already supports this in bidi via sandbox and preloadScripts
<AutomatedTester> ack next
<AutomatedTester> simons: for the atoms are only needed for element displayedness (and get text on top f that)
<AutomatedTester> ... so we can probably see if we still really need them
<AutomatedTester> ... or a different proxy?
<mathiasbynens> s/I think we should unlock more use cases even if the way we do it isn't optimal/imho it’s more important to unlock brand new use cases than it is to spec + implement things that can already be done in a slightly less nice way (on the client or via script evaluation)/
<AutomatedTester> jrandolf: keyboard layouts: the main goal is to support internationalised keyboards
<AutomatedTester> ... I have a design doc on this on classic
<AutomatedTester> ... the MVP description :The ability to test international keyboards
<AutomatedTester> ... there are multiple ways to implement this moving forward
<jgraham_> 100% we should do something better for permissions
<AutomatedTester> automatedtester: permissions, is this not just classic over bidi implementation
<AutomatedTester> Sam Sneddon [:gsnedders]: there are more complex use cases to handle it
<AutomatedTester> jgraham_ (IRC): I think we should improve the way we do it via events to know its there and then handle rather than try pre handle it
<AutomatedTester> jrandolf: drag and drop capabilities: This is different to user interactions
<AutomatedTester> ... there are issues between OS(win/lin). Mouse events need to handle drag and drop as you can't do it
<AutomatedTester> ... let's add a property to know if a client can handle drag and drop
<jgraham_> RRSAgent: make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2023/06/14-webdriver-minutes.html jgraham_
<simons> Are we having the monthly meeting later? I'm guessing not, but I'm checking now
<jgraham_> Yes, it's happening as normal
<jgraham_> RRSAgent: bye
<RRSAgent> I see no action items
<jgraham_> Zakim, leave
<Zakim> leaving. As of this point the attendees have been whimboo, jdescottes, sasha, mathiasbynens, orkon, thiagowfx, JimEvans, sadym, jgraham, lola, simons
<AutomatedTester> jgraham_ (IRC): did you mean to send the bots away?
<RRSAgent> logging to https://www.w3.org/2023/06/14-webdriver-irc
<jgraham_> Yeah, I didn't remember how to end the meeting and start a new one, so it makes more sense to re-invite them
<AutomatedTester_> Meeting: WebDriver June 2023
<AutomatedTester_> chair: David Burns
<orkon> but fighting the video conf software
<AutomatedTester_> scribe: David Burns
<AutomatedTester_> ScribeNick: AutomatedTester
<sadym> couple of mins please
<AutomatedTester_> Agenda: https://www.w3.org/wiki/WebDriver/2023-06-BiDi
<mathiasbynens> (I'll unfortunately need to drop off at the :25 mark, just FYI)

[sadym-chromium]

Implemented.