15:42:34 <RRSAgent> RRSAgent has joined #webdriver
15:42:38 <RRSAgent> logging to https://www.w3.org/2024/04/10-webdriver-irc
15:42:54 <Zakim> Zakim has joined #webdriver
15:43:31 <AutomatedTester_> meeting: WebDriver April 2024
15:44:38 <AutomatedTester_> rrsagent, make  logs world-visible
15:45:09 <AutomatedTester_> chair: David Burns
15:46:17 <AutomatedTester_> agenda: https://www.w3.org/wiki/WebDriver/2024-04-BiDi
15:46:25 <AutomatedTester_> scribe: David Burns
15:46:36 <AutomatedTester_> scribeNick: AutomatedTester_
15:48:10 <AutomatedTester_> rrsagent, create minute
15:48:10 <RRSAgent> I'm logging. I don't understand 'create minute', AutomatedTester_.  Try /msg RRSAgent help
15:48:13 <AutomatedTester_> rrsagent, create minutes
15:48:14 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/10-webdriver-minutes.html AutomatedTester_
15:48:37 <AutomatedTester_> present+
16:00:37 <orkon> present+
16:01:50 <jdescottes> present+
16:02:08 <whimboo> present+
16:02:17 <jgraham1> present+
16:02:35 <sasha> present+
16:03:02 <MaksimSadym> present+
16:03:38 <JimEvans> present+
16:04:16 <lightning00blade> present+
16:05:06 <AutomatedTester_> topic: RFC 185: Add WebDriver BiDi support to testdriver.js
16:05:19 <AutomatedTester_> github: https://github.com/web-platform-tests/rfcs/pull/185
16:06:32 <AutomatedTester_> MaksimSadym: This RFC is about changes to wpt tests. This is not directrly related to this spec but allowing users to start using our APIs. I am not sure if this should be discussed here or in a different meeting but I would like to handle all concerns
16:07:09 <AutomatedTester_> jgraham1: I sorry that I am taking so long to give feedback. There are some potential items for the WG in there
16:07:29 <AutomatedTester_> ... it is mostly  WPT infra question.
16:08:35 <AutomatedTester_> MaksimSadym: The main question in the RFC is changes to testdriver.js and the runner in wpt
16:09:11 <AutomatedTester_> ... the change that I have is to bring in the bare minimum
16:10:03 <orkon> q+
16:10:04 <AutomatedTester_> ... changes that we would need to the changes. We have some examples of the changes that we want to do but
16:10:18 <AutomatedTester_> ... but the changes to the API in testdriver.js is the most critical part here
16:10:20 <AutomatedTester_> ack next
16:10:27 <jgraham1> q+
16:11:13 <AutomatedTester_> orkon: I wanted to mention the RFC has a use case to allow multiple sessions and how we can clean up the event subscriptions
16:12:13 <AutomatedTester_> ... would the RFC block the ability to clean up event subscriptions or is it sufficient to do it on our own
16:12:16 <AutomatedTester_> ack next
16:13:09 <AutomatedTester_> jgraham1: The important question here is "how can we do things to prevent us making large changes to the API in the future?"
16:13:32 <AutomatedTester_> ... and I am happy to take your expertise here for the design
16:14:04 <sadym> q+
16:14:09 <AutomatedTester_> ... but in terms of clean up, I dont think we need to block on it. It might need some more state management in the wpt runner
16:14:55 <AutomatedTester_> ... there are differences between firefox and chrome here when knowing when to handle multiple sessions
16:15:24 <AutomatedTester_> ... and there was a previous suggestion from jdescottes about subscription returning handles
16:16:21 <AutomatedTester_> ... maybe the question is "if we all handle multiple sessions" with caveats then maybe thats what we should do
16:16:24 <AutomatedTester_> ack next
16:17:04 <AutomatedTester_> sadym: one of the ways to support without multple sessions is to have multiplke connections which the spec already has support
16:17:16 <AutomatedTester_> ... and that is a usecase that could handle this scenario
16:17:33 <jgraham1> q+
16:17:37 <AutomatedTester_> ack next
16:17:40 <whimboo> q+
16:18:21 <AutomatedTester_> jgraham1: I am not a great fan of using mulktple connections here and session level is going to be much better especially if we have to do reconnections
16:18:35 <AutomatedTester_> ... and that's better for complete isolation
16:19:10 <jgraham1> I will try to look at the RFC again soon (maybe tomorrow)
16:19:45 <AutomatedTester_> whimboo: if we handle subscriptions to connections would make things more complex
16:19:58 <AutomatedTester_> sadym: I will update the use case
16:20:15 <AutomatedTester_> topic: Add original opener to browsingContext
16:20:25 <AutomatedTester_> github: https://github.com/w3c/webdriver-bidi/pull/664
16:21:34 <jgraham1> q+
16:21:42 <AutomatedTester_> orkon: there have been discussion in the bug. puppeteer allows you to see who the original opener created it.
16:22:15 <AutomatedTester_> ... the idea is when open the navigable that we keep the info and feed it back to webdriver bidi
16:22:18 <AutomatedTester_> ack next
16:22:46 <AutomatedTester_> ack next
16:23:15 <AutomatedTester_> jgraham1: 1 question is we, mozilla, would need to check how easy it is to implement as we may/may not have the info accessible to us
16:23:53 <AutomatedTester_> ... in principle the idea seems ok but the patch does look a little scary and we may need to update the html spec
16:24:06 <AutomatedTester_> ... and we should avoid the hand wavey in this spec
16:24:08 <AutomatedTester_> q?
16:24:10 <orkon> q+
16:24:13 <whimboo> q+
16:24:19 <AutomatedTester_> ack next
16:24:47 <AutomatedTester_> orkon: the html spec changes should be easy but the opener id is discarded quite quickly
16:25:05 <AutomatedTester_> ... so if firefox can implement it then we can do the hgtml spec changes easily
16:25:07 <JaseW> JaseW has left #webdriver
16:25:17 <AutomatedTester_> ... and we will prepate patches
16:25:19 <AutomatedTester_> ack nexty
16:25:23 <AutomatedTester_> ack next
16:26:08 <AutomatedTester_> whimboo: what happens in the case of no opener or we open the window what happens?
16:26:33 <AutomatedTester_> orkon: if the no opner is used then the page wouldnt see it but devtools/bidi woudl still have access to it
16:26:45 <AutomatedTester_> q?
16:27:03 <AutomatedTester_> topic: Ability to bypass network cache
16:27:17 <AutomatedTester_> github: https://github.com/w3c/webdriver-bidi/issues/582
16:28:08 <AutomatedTester_> orkon: we have been working on the network interception spec and we have realised that it is important to bypass the netwrok cache . If there is a cache then the network interception might not be hit
16:28:22 <jgraham1> q+
16:28:23 <jdescottes> I can confirm this is an issue for interception in FF as well
16:28:32 <AutomatedTester_> ... and I think there is a use case for disabling the cache to see how cold start takes
16:28:36 <AutomatedTester_> ack next
16:29:10 <AutomatedTester_> jgraham1: as jdescottes mentioned,. this is a issue in firefox too
16:29:24 <jdescottes> q+
16:29:38 <AutomatedTester_> ... we may need to wire this through the fetch spec so that makes sense
16:30:07 <AutomatedTester_> ... and we need to know at what levels and we do the disabling here. I expect there is a lot of spec work here and probably little implementation work here
16:30:10 <AutomatedTester_> q?
16:30:12 <AutomatedTester_> ack next
16:30:54 <AutomatedTester_> jdescottes: I wanted to clarify. It is an issue for firefox in some but not all caches.
16:31:10 <orkon> q+
16:31:12 <AutomatedTester_> ... in Firefox it is probably better to have users disable it before setting it
16:31:16 <AutomatedTester_> ack next
16:31:47 <AutomatedTester_> orkon: how do you handle the case where there things done by service workers. Can you intercept them?
16:32:02 <AutomatedTester_> jdescottes: we don't handle that and is an open issue
16:32:27 <AutomatedTester_> jgraham1: we would need to update the service worker spec here and our spec doesn't handle this scenario
16:32:53 <AutomatedTester_> q?
16:33:28 <AutomatedTester_> ... and just for clarity, we should handle this scenario but it's not been a priority so far
16:33:38 <AutomatedTester_> orkon: it doesn't work in CDP either so it's a lot of effort
16:33:48 <AutomatedTester_> q?
16:33:51 <AutomatedTester_> topic: Add an ability to locate nodes using computed accessibility attributes
16:34:02 <AutomatedTester_> github: https://github.com/w3c/webdriver-bidi/pull/660
16:34:40 <AutomatedTester_> orkon: this is a feature used in puppeteer and wanted to check if there are concerns?
16:34:56 <AutomatedTester_> jgraham1: I don;t think so, I think the approval just slipped through the cracks
16:35:17 <AutomatedTester_> topic: Emit `browsingContext.contextCreated` while subscribing to the event globally
16:35:28 <AutomatedTester_> github: https://github.com/w3c/webdriver-bidi/issues/696
16:36:20 <AutomatedTester_> sadym:  I noticed in the spec that we don't do this globally but we do it for the specific case
16:36:41 <AutomatedTester_> ... so I think this is a problem, I don't think this was intended
16:37:17 <AutomatedTester_> ... and do we want to re-emit the events if you subscribe again
16:37:28 <jgraham1> q+
16:37:33 <AutomatedTester_> ack next
16:37:59 <AutomatedTester_> jgraham1: I think this is a bug and what you have said is not the behaviour that was intended
16:38:28 <AutomatedTester_> ... and if the use case is not valuable then we should explain or we should fix the bug
16:38:56 <AutomatedTester_> ... especially since no one has implemented this then we should handle the scenario properly
16:39:05 <AutomatedTester_> ... and we should fix the bug
16:40:14 <jdescottes> q+
16:40:19 <AutomatedTester_> I think we should fix it if the context is null or if we don't think this usecase is valuable then we can have a further discussion here
16:40:26 <AutomatedTester_> ack next
16:41:23 <AutomatedTester_> jdescottes: I read this recently, I think this should be handled and should work today but we may want to check again
16:41:31 <AutomatedTester_> q?
16:42:09 <AutomatedTester_> topic: Update handling of "devicePixelRatio" argument in "browsingContext.setViewport" command
16:42:24 <AutomatedTester_> github: https://github.com/w3c/webdriver-bidi/pull/693
16:43:56 <orkon> q+
16:44:04 <jgraham> sasha: At the moment the spec says that we should update the size of a CSS Pixel. But that's not what CDP does, and when we tried to implement it it was complicated. We'd prefer to standardise what CDP does. That's a bit difficult to describe in the spec. We have a PR describing how this works in Gecko, but we need feedback to see if that's similar to what CDP does and others can implement.
16:44:10 <jgraham> ack next
16:44:26 <jgraham> ScribeNick: jgraham
16:46:16 <jgraham> orkon: The pixel size idea doesn't work well. In CDP we get a different result from screenshots and the onscreen display. We currently don't support this kind of emulation for iframes. setViewport makes sense for the top-level context. Are you able to support this in iframes? For users it's important that this has an effect on the screenshot size. I think the current update doesn't cover that. We need
16:46:17 <sasha> q+
16:46:22 <jgraham> to think about that.
16:46:27 <jgraham> ack next
16:47:25 <jgraham> sasha: I'm not 100% sure about iframes; we haven't tested that. We change it on the browsing context, but it might not make sense from the user point of view. For screenshots I think it should make a difference at least in the implementation, it's not clear about the spec.
16:48:38 <jgraham> jgraham: The spec change was based on what Firefox's RDM mode uses, but we need someone to check if that is the same behaviour that other browsers have.
16:48:56 <orkon> I will comment on the PR with what I mentioned after taking an extra look at Chrome implementation
16:49:03 <jgraham> q?
16:49:21 <jgraham> Topic: Geolocation emulation
16:49:29 <jgraham> github: https://github.com/w3c/webdriver-bidi/issues/343
16:50:36 <orkon> q+
16:51:03 <jgraham> jgraham: We know there are requests for this and Puppeteer has it, so this should be the next priority for emulation and overrides
16:51:08 <jgraham> ack next
16:51:57 <jgraham> orkon: We support this in puppeteer. The blocker for using this in BiDi is that we need to be able to provide permissions. It might be possible to use a preload script to override things, but I'm not sure.
16:52:01 <jgraham> q?
16:52:56 <jgraham> jgraham: I assumed we'd just provide mock data, does that require implementing permissions?
16:53:44 <jgraham> orkon: To request geolocation data you first have to give permissions. We could say that providing the data atuo-grants the permissions, but it might make sense to do permissions first, if that's needed cross-browser.
16:55:12 <orkon> q+
16:55:35 <JimEvans> q+
16:55:47 <jgraham> jgraham: Makes sense. We can do the work in parallel though; browsers might have some out of band way to disable the permissions prompt so you could still test that the right geolocation data is returned without supporting the permissions API.
16:55:51 <jgraham> ack next
16:56:39 <jgraham> orkon: Perhaps there is also a relation to the user prompt handing changes; permissions are like user prompts and we could have similar auto-accept functionality.
16:56:45 <jgraham> ack next
16:57:31 <jgraham> JimEvans: Does the permissions spec have a BiDi implementation?
16:57:51 <jgraham> orkon: We have it in Chrome, but I don't know about other implementations. It only covers overrides.
16:59:01 <jgraham> jgraham: We have the permissions spec implemented in classic, but not yet for BiDi (need to check which parts are actually shipping already)
16:59:33 <jgraham> RRSAgent: make minutes
16:59:34 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/10-webdriver-minutes.html jgraham
16:59:49 <jgraham> zakim, bye
16:59:50 <Zakim> leaving.  As of this point the attendees have been AutomatedTester_, orkon, jdescottes, whimboo, jgraham, sasha, MaksimSadym, JimEvans, lightning00blade
16:59:50 <Zakim> Zakim has left #webdriver
17:00:03 <sasha> orkon: `browsingContext.setViewport` command already has a step to check if a specified context is a top-level context, and throw an error if it's not, so we don't need to do anything for iframes
17:00:36 <jgraham> RRSAgent: bye
17:00:36 <RRSAgent> I see no action items