Meeting minutes
Feature detection for BCD collector
github: w3c/
whimboo: there isn't much to discuss at this point. I had a meeting last week about the BCD collection
… we are in need of a way that we can check various versions of browsers to show that new versions of features in bidi went into new browsers
… this is very difficult to keep track of things
… at the moment there is a spreadsheet that tracks this but it would be good to get the info that we need
… my request is that I need feedback on this either here or on the issue
jgraham: I think is a very difficult problem to solve and I am not sure how we can solve this. I kinda feel that keeping this manually updated in a spreadsheet is better. I think one way or another there will be manual process
whimboo: we could try run a test and that will tell us what is supported and what isn't but that is only for commands
orkon: You said that WPT isn't useful but could we use the data that is already in wpt.fyi that has some of this data already
jgraham: We've never been able to do this on any other platform in the past. It seems easy to start but then it gets very difficult very quickly
… I think that having a human do this manually it could be the same amount of effort of automating this
Input events dispatch to top-level frame
github: w3c/
sadym: There is already a discussion that is in the PR. I am a bit stuck with which approach we should be doing here
jgraham: At the moment the spec say we pick and iframe and send events to/from that
… but we may want other data from all frames. e.g. if an overlay is over an iframe and click. We want to have the envet fro the overlay and then the Iframe
… and there might also be a case with what happens when the iframe disappears
… we should handle cancelling when frame goes and stop the propagation from the frame but items can still go that way
… in the future we should probably have a way doing calculations based off the iframe
sadym: my first question: do we want to specify the calc the coords or dispatch to
… and do that on the <missed what was said>
… and then do the calculations more precise and then do htat to the top level
jgraham: yes... we need to work with how browsers actually work and then do that from the top/parent and let that go down to the correct place
… I feel like we agree on the model here
… the main issue is what happens when the iframe disappears
… we can either keep going or can fail
orkon: I think the issue if the iframe disappears. I thought that was solved with the PR from whimboo .
… I think that if the the iframe disappears we should still continue sending the actions
… e.g. mouse down removes the iframe we should continue
… back to sadym if we change to to the top level then the calculations could be a lot harder to do where the current way is already working
whimboo: a follow to the PR, I haven't done this
<orkon> PR I meant w3c/
whimboo: I wanted to give a comment to jgraham if we have to continue then it might be good to handle both case (carry on and error)
… and we would have a default that is managed by an argument
AutomatedTester: Initially, actions were "do as I say", not "do what I mean". actions.mousedown would assume that the element would be in the viewport. Little things like that. Actions should be above the glass. You would just be telling the coordinates and do the action. But you don't necessarily know what's underneath. If I do element.click,
behavior is different.
AutomatedTester: For iframes, behavior has indeed always be different.
jgraham: Do we need to be precise in the spec? Yes definitely
… I know that there are parts that say browser specific but coordiniates is different and we all have the same on that
… my proposal for clients would send details from the top level traversible
… but clients could send them at iframe if they want but then handle the situation if it disappears
… I think we need to follow this up in the issues
orkon: I agree with the error if it doesn't still exist
… we could do the calculations at the beginning
jgraham: I don't think we can beause if we have scroll then all the coords are out
Fail `browsingContext.navigate` if navigation is aborted
github: w3c/
sadym: we have the issue where the user navigated to a page that had a script redirect which then aborted the navigate
… I looked at spec. The spec says we shouldn't fail
… what is the expected behaviour if the navigation is aborted? Should we error or wait until redirection has completed?
jgraham: we're not talking about a redirect but a script that creates a new navigation
… it functionally looks like a redirect but it's doing a stop and then navigate
… I think we should tell the user that we have stopped the navigation and have started a new one
… I know this might look weird for the users
sadym: I would expect either the command to fail or to finish the navigation to "complete", where I can expect the page is ready
jgraham: In the issue you have said that we should treat it like a failure
… it seems weird that we are failing when a new navigation has started
jdescottes: I think we want to have a convenience way to handle this situation
<sadym> I would expect either the command to fail or to finish the navigation to "complete", where I can expect the page is ready
jdescottes: I don't think it makes sense to error here
… I think the webdriver classic way handled this quite well
… and following that way will help people migrate easier
sadym: I think we are mixing 2 concepts. DOM lifecycle and navigation
… if we do DOM then it makes sense
… but while we mix these concepts then its going to cause issues
jgraham: I think I need to reread this issue and come back to you
<sadym> * if we do navigation then
Proposal to remove non-global unsubscribe requests for events
github: w3c/
orkon: I was working on the change to allow unsubscribe by IDs so ahve come up mwith this proposal
… there is a non-global unsubscribve request
… if we want to support it we are going to ahve to split the subscriptions into multiple ways
… a user can subscribe globally and then unsubscribe by ID then nothing is actually going to happen
… this proposal will simplify the way people use it and simplify the spec
jgraham: I agree this is confusing
… it's not undefined. It may do in some cases. I am not sure about removing it as we don't have a way of checking who is using it
… I think we can put ourselves on a path to removing it with warning but not just remove it yet
… it would have been better doing it 2 years ago but we didn't.
orkon: I have a specific proposal is to define a data structure that won't go into the way of it with a warning
… if there are clients that are broken we can always go help them there
… but I feel there won't be many clients affected
jgraham: that says reasonable
jdescottes: this sounds good to me. For the spec changes, do you think we can do the old way and do the way with IDs?
… not sure if you have put thought into that?
orkon: I have the PR that jgraham has reviewed it partially. The issue is to unsubscrube to partial subscriptions
… jgraham has put one model in the issue
… either we preprocess all subscriptions so that partial unsubscibes are easy or we keep the data structure for subscriptions simpler but need to do a complex operation for partial unsubscribes
CDDL extracts in Webref, CDDL support in Bikeshed
tidoust: This is more of meta issue and is linked to the first topic
<jgraham> RRSAgent: make minutes
tidoust: I wanted to see if there are ways to extract CDDL
… and that led me to the way bikeshed seeing it didn't have a way to do CDDL
… which led to other issues with things missing
… this is a pending PR. I need feedback from this group and from Tab
… which means we can have better webref support
… <describes a few issues and how it can affect the naming and spec usage>
… I will be able to start adding things to webref soon
jgraham: I would like to say I am really excited to see this work!
<jgraham> RRSAgent: make minutes