Meeting minutes
<jgraham> RRSAgent make minutes
TPAC
https://
AutomatedTester: We're going to TPAC. All the details are in the link about what days we will be there
gsnedders_irc: can we find out who will be travelling so we can make the remote folks from Europe not have to be around till 6pm PST
ACTION: David to find out who will be remote for the meetings
setWindowRect where position can't be set
github: w3c/
jgraham: This is initially about classic but will affect bidi
… in linux there are times where the answers we are returned does not always match reality
… so for the setter, should it fail or should it ignore you?
… we are doing this in WPT and run it on wayland it will fail and gecko tests time out
… Mozilla has a major push to fix because of the above
… there are different scenarios in the issue that we can do
AutomatedTester: what happens if you set it and it fails?
jgraham: in wayland it allows either x,y or size. not both
AutomatedTester: if I remember that we do the best case here. E.g. try pass it and then do best guess. The main reason was mobile can-'t do any of these things so I am happy with it returning where it thinks everything is
orkon: it sounds like apply as much as possible but we can error. I know we the browser will not always be able to do this. Our position is we can return without setting the position and returning the value of where it thinks it is
jgraham: I think that we need to make sure that we dont break tests. I don't think we need to make this fatal if things don't work out
… and set the value and then return where it thinks it is
gsnedders_irc: do we expect the return the command with error? on mobile we can return errors
AutomatedTester: I am happy to return the 0, 0 and window size and not error?
gsnedders_irc: do we expect people to run desktop tests on mobile?
automatedtester: yes, 80% of tests will work that way unless people think there are feature differences between the platforms. They want write once run everywh
… ere
automatedtester: do we want it to try on desktop and reutn the values it gets to and on mobile error
jgraham: yes. There are some imprementation defined ways to error
Network request ids for auth + CORS preflight
github: w3c/
jgraham: for netwroking intercepts and logging. In the case of redirects we would have a reuqest id that was the same for the whole chain or requests
… what we didn't consider was http auth and cors preflight
… for cors preflight it looks like a separate reuqest
… for http auth it looks like the original requests
… the spec handles this in 3 different ways in the spec
… this has been discussed in the issue. It is unclear what we should do next?
… <explains different ways with request ids, added fields on the objects>
… I would like to know if people have opinions on what approach and what invariants we want to support
orkon: I haven't looked into the issue before the meeting. In the puppeteer we have always considered cors to have separate ids
… if there is auth we have and the dialog is handled and the same id is in the events
… if there is an error we expect a new request id
… looking at puppeteer we do a mix of wha tthe spec has
jgraham: for cors request preflight can be handled as a special case
… for auth we should treat it like a redirect
… which appears to be different to what puppeteer does with cdp. I think jdescottes proposal seems to handle this scenario
… our concern is if there is a auth and the credentials are wrong and it gets itnto a loop doing that over and over
orkon: if we add the auth count is it for per redirect or for the whole chain?
… if we add a parameter that could cause problems down the line
jgraham: I agree a multipart key makes it more complex
… and if chain has the count can handle the count
jdescottes: I was thinking of another design
… one thing we can do is always have a unique id
… and we could have a parent that knows where it could be from and where it is going. E.g. parent for redirect or parent for auth
jgraham: if we do that it creates a new set of invariants and breaks clients
ACTION: Please read the issue and leave comments (all)
File dialog handling
github: w3c/
jgraham: This is more of aquestion. The user prompt handling is in place now we can work on this
orkon: Maksim will be working on this and will update the PR
… what we will want now is that if a dialog is opened that we fire an event back to the client
… and it is similar to the PR
… we don't have the ability to handle this at the moment because of the way that CDP works but we hope to have it updated for bidi
<jgraham> Using the userPromptOpened events
jgraham: that sounds great! I was hoping for that
Navigable rewrite
github: w3c/
orkon: the last time we were updating to use navigables instead of contexts
… it would be good if folks can review it
jgraham: I looked earlier and it mostly looks right. I will try read it again very soon. Thanks for doing all the editorial work
orkon: I've updated links etc
<jgraham> RSSAgent make minutes
<jgraham> RRSAgent make minutes
<jgraham> RRSAgent: make minutes