Meeting minutes
RFC 185: Add WebDriver BiDi support to testdriver.js
github: web-platform-tests/
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
jgraham1: I sorry that I am taking so long to give feedback. There are some potential items for the WG in there
… it is mostly WPT infra question.
MaksimSadym: The main question in the RFC is changes to testdriver.js and the runner in wpt
… the change that I have is to bring in the bare minimum
… changes that we would need to the changes. We have some examples of the changes that we want to do but
… but the changes to the API in testdriver.js is the most critical part here
orkon: I wanted to mention the RFC has a use case to allow multiple sessions and how we can clean up the event subscriptions
… would the RFC block the ability to clean up event subscriptions or is it sufficient to do it on our own
jgraham1: The important question here is "how can we do things to prevent us making large changes to the API in the future?"
… and I am happy to take your expertise here for the design
… 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
… there are differences between firefox and chrome here when knowing when to handle multiple sessions
… and there was a previous suggestion from jdescottes about subscription returning handles
… maybe the question is "if we all handle multiple sessions" with caveats then maybe thats what we should do
sadym: one of the ways to support without multple sessions is to have multiplke connections which the spec already has support
… and that is a usecase that could handle this scenario
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
… and that's better for complete isolation
<jgraham1> I will try to look at the RFC again soon (maybe tomorrow)
whimboo: if we handle subscriptions to connections would make things more complex
sadym: I will update the use case
Add original opener to browsingContext
github: w3c/
orkon: there have been discussion in the bug. puppeteer allows you to see who the original opener created it.
… the idea is when open the navigable that we keep the info and feed it back to webdriver bidi
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
… in principle the idea seems ok but the patch does look a little scary and we may need to update the html spec
… and we should avoid the hand wavey in this spec
orkon: the html spec changes should be easy but the opener id is discarded quite quickly
… so if firefox can implement it then we can do the hgtml spec changes easily
… and we will prepate patches
whimboo: what happens in the case of no opener or we open the window what happens?
orkon: if the no opner is used then the page wouldnt see it but devtools/bidi woudl still have access to it
Ability to bypass network cache
github: w3c/
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
<jdescottes> I can confirm this is an issue for interception in FF as well
orkon: and I think there is a use case for disabling the cache to see how cold start takes
jgraham1: as jdescottes mentioned,. this is a issue in firefox too
… we may need to wire this through the fetch spec so that makes sense
… 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
jdescottes: I wanted to clarify. It is an issue for firefox in some but not all caches.
… in Firefox it is probably better to have users disable it before setting it
orkon: how do you handle the case where there things done by service workers. Can you intercept them?
jdescottes: we don't handle that and is an open issue
jgraham1: we would need to update the service worker spec here and our spec doesn't handle this scenario
… and just for clarity, we should handle this scenario but it's not been a priority so far
orkon: it doesn't work in CDP either so it's a lot of effort
Add an ability to locate nodes using computed accessibility attributes
github: w3c/
orkon: this is a feature used in puppeteer and wanted to check if there are concerns?
jgraham1: I don;t think so, I think the approval just slipped through the cracks
Emit `browsingContext.contextCreated` while subscribing to the event globally
github: w3c/
sadym: I noticed in the spec that we don't do this globally but we do it for the specific case
… so I think this is a problem, I don't think this was intended
… and do we want to re-emit the events if you subscribe again
jgraham1: I think this is a bug and what you have said is not the behaviour that was intended
… and if the use case is not valuable then we should explain or we should fix the bug
… especially since no one has implemented this then we should handle the scenario properly
… and we should fix the bug
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
jdescottes: I read this recently, I think this should be handled and should work today but we may want to check again
Update handling of "devicePixelRatio" argument in "browsingContext.setViewport" command
github: w3c/
<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.
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
to think about that.
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.
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.
<orkon> I will comment on the PR with what I mentioned after taking an extra look at Chrome implementation
Geolocation emulation
github: w3c/
jgraham: We know there are requests for this and Puppeteer has it, so this should be the next priority for emulation and overrides
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.
jgraham: I assumed we'd just provide mock data, does that require implementing permissions?
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.
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.
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.
JimEvans: Does the permissions spec have a BiDi implementation?
orkon: We have it in Chrome, but I don't know about other implementations. It only covers overrides.
jgraham: We have the permissions spec implemented in classic, but not yet for BiDi (need to check which parts are actually shipping already)
RRSAgent: make minutes