Meeting minutes
<jgraham> RRSAgent: make minutes
https://
<jgraham> Please fill in https://
Bypass CSPs for async calls, nested calls, calls to content scripts
github: w3c/
jdescottes: I have been looking it how we should bypass CSP for non-trivial cases
… initially Chrome was doing things here and we have aligned Firefox to the chrome way and it is not spec'ed yet
… we need to define the behaviour to spec it
… we currently only do this for sync
… do we want to update the implementation to default to bypasses CSP in all cases or should it be an explicit flag
… one thing worth noting is that devtools doesn't follow this and it enforces CSP in eval which will be different
… so what do we want to do here?
sadym: it's more or less related to scipt eval with bidi
… <describes issues in devtools>
orkon: I wanted to summarise that we are ok with the works currently
… it is hard to align here related to tasks
… i think the current default behaviour is expected by automation users
<sadym> sadym: according to the JS spec, the micortasks scheduled with setTimeout are not attributed with the source, so there is no way we can attribute them as "trusted" or "force to run". However we can allow for "thenables" to be run in such cases.
<sadym> sadym: TL;DR; we can "promise.then", but cannot "setTimeout()"
<sadym> aq+
jdescottes: do you think that there is a usecase for bypassing CSP using thenables?
sadym: we cannot test when one chain is broken because thenables execute immediately
… we do have use cases for thenables but with settimeout it doesnt work
orkon: I didn't test the thenable case in settimeout in CSP ... but I think that would be fine
jdescottes: I think in that case we wait for the PR for script eval is fully merged before we move on with this
Bypass CSPs as a separate command./ configuration
github: w3c/
jdescottes: by bypassing CSP on the page for anything that might be handled... it's something that playwright use this, and they find it is very useful. This is for situation where script has nonce defined. this would be scoped to browsing context or global context
jdescottes: there is a playwright issue linked please read that
orkon: I think we should have it... i think that bidi should be able to control this
Add subscription ID to event data
github: w3c/
jimevans: we added the ability to sub to events on user context
… most of the events have the browsing context that they are coming from
… if you do it via the user context it is hard to track where it is coming from
… it's not impossible but definitely not ergonomic
… this has been rasised by the selenium contributor
… there is a proposal that has an array of subscription ids. I am looking to get discussion around this to improve the use case
jgraham: I think we have 2 option. Add user context to the event. I think this ia good idea anyway
… adding the id to the event is a good idea and I feel we have discussed before and forgot why we didn't do it.
… I dont know if we are doing a de-duplication of events if you resubscribe
… I like the model as it makes things easier on the client side
sadym: from what I remember the subscription can be set by different users and that was the concern if user a subscribes and user b unsubscribes
… in the user context it wont be a problem
jimevans: when I was discussing it with the user, I mentioned that if we returned the subscription ids to the event
… there are cases where events could leak out info
… if multiple clients subscribe to the same events it could be a problem
… we can add ids or user context could be a valid solution but not sure if there is a reason not to
jdescottes: when we added the subscription model we didn't consider the events too much because we were thinking about the unsubscription model. I can't talk for the security issues
jgraham: I think it's a good poiunt about unsub breaking encapsulation
… if we think things shouldn't share any state but that should be solved by the multiple sessions keeping things separate
… everything else depends on the client to enforce boundaries
… from this discussion it solves the use case we should do it
Autofill trigger
github: w3c/
sadym: this is a PR from yoav. There are some misunderstandings and we need to discuss
… we only test the 3rd part which is filling in the data and it is the least contriversial part
… even with that I think that the PR from yoav makes sense and I think we should approve
yoav: thanks for summing it up properly and I will handle concerns
jgraham: I am not an expert on how data will get in and be stored
… I am curious what blaze has to say about this from webkit
blaze: I am looking at the PR, I think we're very close
… the discussion we were having was around addresses and checkout
… if we are only solving it for that then it's fine, if it's logout etc then we need to discuss it further
… as long as we have the fields designed. I think the tests also need to be shown
yoav: this can be scoped to addresses and then work from there
… beyond that we have a set of outdated wpt mocks that need revisiting
… if this lands in the spec I can see about landing this into chromium and making sure the wpt tests are updated
<sadym> Example of the test using trigger autofill API: https://
yoav: this also goes with an event for autofill being redone
… this tells the browser when to redo the autofill
blaze: there is the classification vs putting this into the DOM.
… I think if we make sure the classication is done properly
… and if the browser doesn't get the classication right how do we know what needs fixing
… I am trying to understand waht is next
… I will look and if there are more tests that would be great
sadym: there is a link to a test that uses pure bidi
<yoav> web-platform-tests/
Allow for specifying schema in "proxy"
github: w3c/
sadym: what is specified in the spec isn't what chromium does, chromium does a lot more
… I have reworked the proposal and it is backwards compatiable
… please look and consider this for merging
Enable and disable scripting via BiDi
github: whatwg/
sadym: we only have left this last bit that is in the html spec
… there are some reservations still
<sadym> sadym: whatwg/
sadym: this is the best that we can do for now. Do we need full alignment or can we move forward?
jdescottes: I can't answet the question but I will follow up with Simon tomorrow
ACTION: jdescottes to follow up on this
jgraham: it seems in the end it sets out the 3 scenarios. in 3rd scenarios if the page loads and disavles script...
… it says practical implementation can trump the theoretical purity
… if we have a page that has runs script and then disables script it might later run some script
… we should have a plan to align here for the fuutre
… my read is that Simon is that as long as everyone is happy we can move ahead here
sadym: practically speaking, if we can't reproduce it then we can continue doing with what we are doing
jgraham: the other use case is weakmap finalisers
… this is a edge case but we need to say that we are ok with the code running
sadym: in that case we have the same case and we restrict finalisers or we don't restrict them
jgraham: in practise disable script is an edge case and I doubt many people would try do this
… it's ok to say for the spec to say it should do it but it could be hard to implement
… and we say that if scripting is disabled that some script may still get run
<jgraham> RRSAgent: make minutes
`emulation.setMaxTouchPoints` invokes legacy archived specification
github: w3c/
sadym: this is a step forward for mobile emulation, please can people review
jgraham: pointer events does this and we shouldn't be referencing touch events is a not a good idea. I haven't read the PR
… if we are using legacy APIs we should suggest to people to use a non-legacy API for things
<jgraham> s/should suggest people use a non-legacy API for things/just have a non-normative note about what implementations implementing those nonstandard APIS might want to do, because all the behaviour here is nonstandard anyway/
<jgraham> RRSAgent: make minutes
<jgraham> RRSAgent: make minutes