Meeting minutes
Scrollbar emulation
github: w3c/
sadym: this is what we discussed 3 weeks ago about scrollbar emulation
… I think we have consensus. What I wanted to bring in this PR to be more generic
… <discusses there a number of different items to store data>
… we currently have a singleton for the remote end but not for the session
jgraham: I only briefly looked in the PR but it looked like a good way to store data for the we are setting up in the session
… and this will lead to being more consistent with how we look up data
sadym: this is a blocker for all emulation that we are going to specify. I would like to reuse this as I build out the other emulation. Please can people unblock me by reviewing this PR
whimboo: I am on PTO over the next week. If others can help review. I looked and it looked ok for now
jgraham: I think it would be good to have the config item split out into a new PR and then have a PR for emulation that then uses it
sadym: this would be odd and it would need an example of how to use it so that's why its in that PR
jgraham: it's fine to be in the PR but ideal case would be PR for infra and a PR for emulation to see it being used but I can do it in 1 PR
Proxy configuration
github: w3c/
sadym: we discussed this in the last meeting. I would like the PR to be reviewed. It uses the existing description of what proxy values
… it's an extension of the existing wording. I tried to update the wording but it didn't make much sense
Screens emulation
github: w3c/
sadym: I started looking at screen emulation and have started work on the bidi spec work
… I have a generic question for consumers
… there are physical and there emulated screens
… do we want to have a way to move between physical and emulated screen
… and do we want to have atomically handle screen emulation
jgraham: reading this issue, I don't think we should handle the idea of reconfiguring the OS. We should only allow browser
… this leads to physical and emulated screens
… this could hit limitations like a emulated screen is bigger than a physcail screen
… and I am not sure I understand the trade off of atomic vs the other way
sadym: implementation for us is emulated screens in headful or headless screens
… in headful we can only use physical screens
… I want to also make sure that if we want to have a split webview for a presentation to make sure the 2 windows are in sync
… I can see there are tradeoffs
<sadym> in Chrome, we can support real devices only in headful mode, and emulate screens only in headless mode
jgraham: I think would be to document this in the issue. I don;lt have enough gecko knowledge to know what we can/can't do but if we can have the use cases documented and what chromium can also do that would be quite useful
screencasting
github: w3c/
sasha: this is a call for a review of the proposal that I have put up. I do have 1 question which how do we handle audio. The get media can also get the audio. Gecko can't handle the audio just yet but I wanted to see if there was concensus on if it is needed or not?
sadym: I haven't read the PR. I will look. For clarification, you use media encoding for creating the file
sasha: we get the stream and then encode it into a blob that we eventually save into the file
sadym: I wonder how we will test this in WPT
sasha: in playwright they do a way to do this type of testing
jgraham: this won't be easy but there are way to test media in wpt already
… it will be hard but not impossible to test this
Bypass CSP
github: w3c/
jdescottes: I opened a PR on bidi. This works in the same way that other config commands works
… and we have a hook that allows people to check that CSP
… there is also a PR against CSP spec that I want to check with this group
… <discusses cases>
… should we only do the simple CSP at document initialisation or should it do everything
… I wonder if we want to be thorough or just the simple case?
sadym: I don;t know what we do... but I would be surprised if we do deep changes to fetch but I think we should do the proper thing from the beginning and implementations do their best effort
Wait for request animation frame on action commands
github: w3c/
jdescottes: this last topic is to do with handling actions that will scroll the element into view
… and the browser does the scrolls in an async way
… so how do you want to handle this... or do we just do the simple way because old tests are already handling the timing and we might suddnely break things
sadym: this sounds like a breaking change that I would rather have jgraham or simonstewart to answer
jimevans: I would prefer people to use bidi but I think we need to solve scrolling in bidi so not sure we can have bidi as a solution just yet
jgraham: I was looking at CSSOM has scroll into view returns a promise but I don't think it's handled
… I think there is a bit of history that when we change things like this that people rely on current behaviour
… it would be good to test the change on a large test suite
jdescottes: if we update classic it would need an opt ok. If there is a promise on the spec then great. There are a use case where a series of JS fired when the scroll happened. I am happy to have bidi do scroll into a view that relies on this promise and if there are more complicated cases that they handle that themselves
jgraham: for actions we handle the click event before we move on to the next part of the action chain
… so then with a scroll we wait for the promise to return and then then event loop to spin
… I think there would be some logical idea that after the scroll action that we spin the event loop to handle events that could have been created by that action
jdescottes: would we consider this for classic or just bidi
jgraham: if we put scroll into actions which would make it new so there would not be a compatibility things
… which means we can work in classic or classic. If we were changing the API that is there its hard to existing API because people could be relying ont hat behaviour
… so we can add it here and have it spin the event loop
<jgraham> RRSAgent: make minutes