15:57:24 RRSAgent has joined #webdriver 15:57:28 logging to https://www.w3.org/2024/06/12-webdriver-irc 15:57:30 Zakim has joined #webdriver 15:57:59 Meeting: WebDriver BiDi 15:58:08 Agenda: https://www.w3.org/wiki/WebDriver/2024-06-BiDi#Agenda 15:58:13 RRSAgent: make minutes 15:58:14 I have made the request to generate https://www.w3.org/2024/06/12-webdriver-minutes.html jgraham 15:58:18 RRSAgent: make logs public 16:00:25 orkon7 has joined #webdriver 16:00:28 orkon7 has left #webdriver 16:00:50 orkon has joined #webdriver 16:01:23 jdescottes has joined #webdriver 16:02:40 Chair: jgraham 16:02:41 sasha has joined #webdriver 16:02:55 lightning00blade has joined #webdriver 16:03:17 jugglinmike has joined #webdriver 16:03:27 present+ 16:03:39 jimevans has joined #webdriver 16:04:31 present+ 16:04:33 present+ 16:04:34 ScribeNick: orkon 16:04:37 present+ 16:04:41 present+ 16:04:44 present+ 16:04:45 present+ 16:05:00 Topic: Should the "New Session" command return default values for capabilities that have not been specified? 16:05:15 simonstewart has joined #webdriver 16:05:17 GitHub: https://github.com/w3c/webdriver/issues/1813 16:05:34 present+ 16:06:24 jgraham: should we return the defaults for capabilities that are not specified? at the moment in classic webdriver the spec says you return certain capabilities always, such as browser name, or capabilities that you specified or the resolved value. 16:07:31 jgraham: this question came up around the unhandled prompt behavior and if you should get something back if you did not specify anything. Safari follows the spec, and Chrome and Firefox return the values always 16:07:41 q? 16:08:03 jgraham: should we continue handling this per capability or handle it in a general way? 16:08:04 q+ 16:08:11 ack next 16:08:21 simonstewart has joined #webdriver 16:08:28 ScribeNick: jgraham 16:08:57 q+ 16:09:05 orkon: We would prefer to always return resolved capabilities but don't feel strongly. It seems like it might be easier for the users to return what's actually used by the session. 16:09:13 ack next 16:09:23 ScribeNick: orkon 16:09:45 simonstewart: the returned capabilities are usually for the local end to figure out what the remote end supports 16:10:08 q+ 16:10:14 simonstewart: the criteria to decide should be if the client would need the information and correct the request based on the response 16:10:43 simonstewart: the safe way is be to return everything. Otherwise, we need to decide on teh case by case basis 16:10:45 ack next 16:11:43 q+ 16:11:54 jgraham: so returning it always seems to be the only backward compatible way to move forward. The only thing is that we do not return the full list of Firefox specific properties. It is possible that there are cases where the list of possible values/capabilities is too large 16:12:31 jgraham: returning the defaults make a more uniform API 16:12:36 ack simonstewart 16:13:22 simonstewart: there are some capabilities that you do not want to return in full, like proxy configuration. For properties it makes sense to exclude them or provide a subset 16:13:40 simonstewart: perhaps we should put in the spec how to return the value if you need to return it 16:14:09 jgraham: the spec has this but for many capabilities we do not default to returning values 16:14:17 q? 16:14:46 Topic: Update spec to define things in terms of Navigables - anyone who has time to work on that? 16:14:57 github: https://github.com/w3c/webdriver-bidi/issues/91 16:15:24 jgraham: a while ago the html spec moved away from the browsing context concept 16:15:34 jgraham: the concept is now navigables 16:15:49 jgraham: unfortunately, we have not yet upadted the spec to be in terms of navigables 16:16:15 jgraham: some time ago we decided not to change the api but change the spec text to use navigables in the spec prose 16:16:48 jgraham: this came up because orkon was updating the HTML spec to integrate navigables with the WebDriver BiDi 16:17:26 jgraham: from my side it is unlikely that I will have time any time soon but can help someone who wants to update the spec 16:17:29 q+ 16:17:36 ack next 16:17:40 ScribeNick: jgraham 16:18:45 orkon: We discussed this. It will be really nice to update, but we don't have a lot of time at the moment. There's already a PR that hasn't landed which puts notices to be aware of the terminology. Proposal is to make incremental updates rather than change it all at once. 16:19:12 ScribeNick: orkon 16:19:32 jgraham: makes sense, the q is what we need to get that PR landed 16:19:48 https://github.com/w3c/webdriver-bidi/pull/565 16:21:00 orkon: there are pieces from the PR that related to navigables and they can be probably landed separately 16:21:04 q? 16:21:53 q? 16:22:06 Action item: Aex to extract the relevant pieces from PR 565 and create a new PR 16:22:18 s/Aex/orkon/ 16:22:31 Topic: Prompt Handler for beforeunload 16:22:44 github: https://github.com/w3c/webdriver-bidi/pull/681 16:25:35 jgraham: the next topic is about prompt handling, not only the beforeunload. The context is: there is a PR to add the prompt handling support based on the WebDriver spec changes. It allows to specify defaults for the BiDi only sessions. In WebDriver the handler applied to all prompt types except for beforeunload. In BiDi, you can get an event that 16:25:35 there was a beforeunload prompt and the client can handle it. But that means that the way things are specified in Classic, default prompt handler does not apply to beforeunload. The question is if we want to carry this over to by and what to do when we start treating file dialogs and auth prompts. The default in classic to always ignore. And for 16:25:35 file dialogs the accept does not make sense as a value. What should we do about that? 16:25:40 https://github.com/w3c/webdriver-bidi/pull/681#discussion_r1634703120 16:26:48 jgraham: there are multiple options. For example, we can overwrite the behavior in Classic. We could change the semantics but it might mean that things might break when updating from Classic to BiDi. We could also only allow ignore and dismiss in BiDi or remove the default. 16:26:50 q+ 16:26:58 ScribeNick: jgraham 16:27:00 ack next 16:28:38 orkon: We discussed on the PR. From our perspective changing the semantics and having the default apply to all prompt types seems best for BiDi. But not sure about compatibility with classic. If you're updating from classic, users might expect the default to apply to all dialogs including beforeUnload, so maybe it would fix expectations. 16:29:21 orkon: In general it's not a blocker for this proposal. We could live with accept not working for all prompt types. 16:29:37 ScribeNick: orkon 16:30:59 orkon: we could just make it completely breaking if you switch to BiDi. We could make it than we support only what we currently support. You can still make it work for classic+bidi session so that the syntax changes then. 16:31:14 s/orkon:/jgraham: 16:31:22 q+ 16:31:39 jgraham: question to the selenium users: do you want to do more with the prompt handling compared to classic? 16:31:43 ack simonstewart 16:32:05 simonstewart: in the selenium project, we will be migrating the users to WebDriver BiDi as soon as possible 16:32:35 q+ 16:32:42 simonstewart: everyone knows that the long term future will be BiDi. The only thing we need Classic for, for teh browsers that do not support BiDi 16:32:50 ack next 16:34:28 jimevans: also in selenium, we can, for a mixed session, tailor the behavior of the prompt handler for the prompts that are not part of the classic spec to match the existing behavior. Because once we enable BiDi in Selenium, we can have in one go update our methods that do prompt handling to accomodate the behavior so that the user experience is 16:34:28 no different 16:34:49 jimevans: so I do not see a problem with having the prompt handlers being different for bidi than for classic 16:34:50 q? 16:36:34 jgraham: ok what I should try is for classic: you can either provide a string value or you can provide an object and if you provide a default key on the object, then it is the default for everything. And specific keys need to be defined to override the default. Then any navigation will fail if you do not re-define the default for the beforeunload. 16:36:34 If we cancel the prompt, the navigation is also cancelled. I think it is compatible with classic but also has better semantics for BiDi 16:36:37 q? 16:36:49 Topic: Bypass network cache behaviour 16:36:57 github: https://github.com/w3c/webdriver-bidi/pull/721 16:39:32 jgraham: this one is about request interception and how we force bypassing the network cache. I put a PR which was designed around the idea of setting the cache mode on requests. So when you have a request, it will set the cache mode to no-store, which means no reading or writing to the http cache. Unfortunately, it does not quite match what 16:39:33 browsers do at the moment when you disable caches in devtools: 1) cors preflight cache which is always used 2) image cache and possible other caches So the question is how much flexibility do we care about here? Should we try work with low level primitvies? Or do we actually only care about bypassing all caches? 16:39:40 jgraham: is that going to be the easier way to solve this? 16:39:43 q? 16:39:44 q+ 16:39:48 ack orkon 16:39:52 ScribeNick: jgraham 16:40:10 jdescottes has joined #webdriver 16:41:57 orkon: We also found that Firefox uses no-store by default but chrome uses reload, so Chrome still writes responses to the cache. We couldn't find use cases which require controlling different kinds of caches individually. Maybe there are some wpt use cases, but we haven't run into them yet. For testing scenarios you mostly care about bypassing everything. Also for interception to catch every request. 16:42:03 So it sounds like a single bypass cache setting would be sufficient. We could extend in the future with additional parameters if we needed. Question is which cache mode should the bypass use, or how important is that?\ 16:42:07 q+ 16:42:13 ScribeNick: orkon 16:42:14 ack next 16:43:03 jgraham: I think it is important that we specify a specific cache mode. bypassing the cache meaning no writing to cache makes more sense. 16:43:42 jgraham: we empty the cors cache or whether we just bypass it. But then when you disconnect webdriver session, the cache will be still populated with the cache 16:44:08 jgraham: I noticed that the spec has primitivees for clearing the cache but not by-passsing 16:44:32 jgraham: and what happens with preflight requests if you toggle the bypass setting 16:44:48 q+ 16:44:48 q? 16:44:52 ack orkon 16:44:57 ScribeNick: jgraham 16:46:12 q+ 16:46:16 orkon: I need to look at what we do for the CORS cache. We can change the cache mode; if we use reload we don't need to change but Firefox would. For memory caches we clear the cache. I need to double check on bypass vs clear. For HTTP we definitely don't clear, but I'm not sure about the other cache types 16:46:22 ack jdescottes 16:46:26 ScribeNick: orkon 16:46:45 jdescottes: in Firefox we only bypass but do not actively clear anything, at least with DevTools 16:47:38 jgraham: I think bypassing makes more sense than clearing. It sounds like at least for some of the caches it is hard to implement and memory caches can be cleared at random. So perhaps it is less imporant. 16:47:40 q+ 16:47:45 ack next 16:47:52 ScribeNick: jgraham 16:48:49 orkon: I think what happens to the cache after you've done your tests is less important. it's more important to be able to test a cold start of the application and measure the time taken, data transferred, etc. 16:49:02 ScribeNick: orkon 16:49:06 q? 16:49:53 jgraham: we should change the command to just set cache bypass to true or false and for now we should set the specific cache mode and it should probably bypass the cors cache and be a bit more handwavy about memory caches 16:49:57 q+ 16:50:04 ack next 16:50:13 ScribeNick: jgraham 16:50:38 orkon: I think there's an open HTML issue about the image cache, but implementations may also have more caches than that. 16:50:48 ScribeNick: orkon 16:51:13 jgraham: it might be that for image cache we could specify better but we could also mention implementation-specific caches 16:51:21 q? 16:51:33 Topic: Network events for data URIs 16:51:42 github: https://github.com/w3c/webdriver-bidi/issues/727 16:52:40 jdescottes: Firefox is implementing data URIs for network events. So Firefox only emits responseCompleted. So BiDi spec expects a beforeRequest event before responseCompleted. 16:53:14 jdescottes: that is also related to the topic of network interception what we should for data URIs and if we only emit response completed and that is fine since it cannot be intercepted at this stage 16:54:01 jdescottes: do we want the full or limited set of events? do we want to have the interception for those requests? 16:54:12 q+ 16:54:14 ack next 16:54:22 ScribeNick: jgraham 16:55:55 orkon: Chrome emits those events but doesn't support interception for data requests. Data requests don't come from the network, so how much it's applicable to data URLs is a question. It would be great to have the full set of events from the client perspective so you get the same workflow as for other requests. At the same time if there's one event with all the data then it's probably acceptable. 16:56:03 q+ 16:56:10 ack next 16:56:22 ScribeNick: orkon 16:56:53 jgraham: we could a completely separate events for data URIs and if that just has a single event it might break a few invariants 16:57:02 q+ 16:57:05 s/break a few/break fewer/ 16:57:12 ack next 16:58:26 jdescottes: so a separate was a good solution. So we will still need to modify the spec that data URIs do not trigger responseCompleted. In DevTools UI data URIs usually show them in the same place. So users are likely to treat data URI as regular URIs. So I would prefer to have the full set of events as well. 16:58:59 jgraham: sending one event instead of three would be more efficient 16:59:03 q+ 16:59:08 ack next 16:59:16 ScribeNick: jgraham 17:00:38 orkon: I'm wondering if there's a use case for data urls. Potentially an app could fetch some data and insert it as data uris, and maybe there's some scenario where you want to modify that. But it's an argument for having three events because that would make it easier to cover data uris for interception vs a single event. 17:00:47 ScribeNick: orkon 17:01:11 jgraham: it sounds like people are in general in favor of making 3 events 17:01:26 jgraham: it sounds like we should change the spec change to make sure we are emitting them 17:01:51 Cheerio, everyone 17:01:56 RRSAgent: make minutes 17:01:57 I have made the request to generate https://www.w3.org/2024/06/12-webdriver-minutes.html jgraham 17:02:43 zakim, bye 17:02:43 leaving. As of this point the attendees have been orkon, jimevans, sasha, jgraham, jdescottes, lightning00blade, simonstewart 17:02:43 Zakim has left #webdriver 17:02:56 RRSAgent: bye 17:02:56 I see 1 open action item saved in https://www.w3.org/2024/06/12-webdriver-actions.rdf : 17:02:56 ACTION: item to Aex to extract the relevant pieces from PR 565 and create a new PR [1] 17:02:56 recorded in https://www.w3.org/2024/06/12-webdriver-irc#T16-22-06