Meeting minutes
RRSAgent: make minutes public
Streaming API
github: w3c/
<jdescottes> present_
sasha: for the streaming. API I am asking if we can have a review of this. We think we have figured out to make this work. At the moment it does the general structure and does script evaluation
… it does not cover network or screencast just the general structure
… please review the PR or ask questions
orkon: do. we have a usecase for returning a returning a stream from javascript?
jgraham: from the spec, the streams in fetch are the same JS streams
… from the spec point we need to take a DOM stream object and return it
… in terms of use cases then there are some like "fetching" some large JS object and you want to access from webdriver
… the point was trying to get DOM streams to then we go from there. This makes it easier to write tests
… but I don't think the use cases will change to much from what we have in the spec
<orkon> we will review the PR first
Add "imageSize" argument to "browsingContext.captureScreenshot" command.
github: w3c/
sasha: there is a use case for adding a imageSize to capture screenshot to allow people to get the screenshot size back
… this alllows agentic usecases and it only specifies the maximum size and will try downscale to the maximum size that people are suggesting
… please review and/or ask questions
An event/data attribute to know when a frame/window.open finished loading
github: w3c/
sasha: we would like to have an event or attribute has finished loading. we would like to have this as a property on the context creation event
orkon: I was curious how it will know if it will be navigated. I can see this for window open but might not happen if things are lazy loaded
sasha: for iframes we can see if there is an attribute is set. If it is lazy loaded we haven't got that yet and will need review
gsnedders: I am interested in how we would put this into the html spec. I think that is the more interesting aspect of this work
jgraham: do you have a specific thought on this?
gsnedders: like where would we put the hooks for this? there are some complicated pathways through the spec here
sasha: I have taken a look today and there are a lot of paths. There are some areas that need updating. but it didn't look too difficult
jgraham: if not this then. what else? There are cases where could people do things that could land up against about:blank when they don't realise
sasha: the other approach of having an event will have the same issue as adding it as a property. We still are going to have to figure out when to send the event and where to put it in the spec
gsnedders: I don't think the approach from webdriver is the issue, I think it will be interesting getting the html spec as I don't think people implement this properly
… firefox and webkit have a lot of edge cases here that chromium might not
… and it will be good to have an idea of "what counts" otherwise users could hit a lot of edge cases
<gsnedders> (to slightly add: I think Firefox and WebKit at times load initial about:blank when Chromium doesn't?
jgraham: I wonder what the situation is today. Firefox is fixing things here and the navigation spec is making people align
… everything could be a edge case here. Is this about blank or is this about to navigate
… if we can solve the 95% case here that would be good for end users
… and this could lead to people optimising. the platform when people will be using webdriver or when it's not
orkon: I think there are 2 issues here. Lazy frames in puppeteer came up against not having about blank. There are optimisations here that could cause problems.
… we need to make sure that attribute doesn't contradict what happens when a frame actually runs
jgraham:
jgraham: I agree with the navigation api we need to make sure that does what we need
… we need to dig into this further
… with lazy loading I don't know what events might be emited
… and lazy loading might need it's own solution here
gsnedders: the other thing that we need to look at is things around script execution. e.g. if you start execution in about blank and then it navigates what do you do? It's something that needs to be thought about
<gsnedders> ...not directly related to this issue, but it's a lot of what causes user issues
jgraham: the motivation is to prevent people running scripts in about:blank that are known to be about to navigate
UserContext returned on events
github: w3c/
AutomatedTester: this is just a PR that was for the work that jimevans raised before it should not be controversial. This was done around the work for parallelisation with selenium. Please review
… it does open a question do we want to do something similar for browsing context but that can be answered later
What counts as "the DOM events generated by the last invocation of the dispatch tick actions steps"
github: w3c/
gsnedders: I posted this a few weeks ago around the behaviours of actions on mobile
… there are a lot cases where waiting for a tick could lead to certain gestures never actually happening
… this could lead to OS interpretations of gestures not doing what the user wanted .e.g. a tap waiting for something could look like a press and hold while the other item finishes
jgraham: we have talked about this before, I would need to check what firefox is doing but I think we just inject things into the event loop. The best person for this is whimboo who isnt around at the moment
… I expect we want to improve the spec here
… do you have a proposal on how to fix it
gsnedders: not at the moment
… the longer asnwer is there are times when we want to wait and times we dont and it is hard to decide
… and this can make WPT fail en masse
… I would like to avoid "wait for any click or events to fire"
… this is around how gestures are done and none of that is really specified
orkon: in the past I think we decided to make sure that we didn't do things that lasted more than the `performActions` call
jgraham: that is correct
… I think the issue is the opposite. there are times where we want pointer down and pointer up to happen faster than a tick to count as an gesture properly for "tap"
gsnedders: this is a question of "how long do you want the event loop to spin for" which means you could wait a time here
jgraham: this used to work in firefox as "do an action" and then queue up it's events and then we inserted callback to make sure that the events that should happen would fire
<gsnedders> w3c/
jgraham: [explains scenario about actions with a setTImeout]
… and the previous spec didn't count on how we could interact with html
gsnedders: there is a lot of "implementation defined" items here
<yezhizhen> This do reminds me of https://
orkon: I briefly checked chrome and it doesn't do anything around dom. It waits for the ticks to complete and move on which might not be correct.
gsnedders: a lot of the UIKit WebKit code is async which makes this a lot harder
<gsnedders> (The AppKit WebKit paths are sync, which means this all works correctly on macOS.)
RRSAgent: make minutes