Meeting minutes
Display: None and DIsplay:contents
github: w3c/
whimboo: we've had this issue open for a while
… I noticed that if you do actions we have difference of how browsers do this. E.g. Firefox errors and the others dont
… it would be good to define what the behaviour should be here
… when speaking to jgraham we should likely error
automatedtester: with display:none do we know the location of the element?
jgraham: no, we don't. Display none has nothing in the layout
automatedtester: with actions we should be going through the glass so I ma not sure the correct way here? Should we go up a level in the DOM? or just error?
jgraham: I think we should solve this with an error as this is an edge case. Safari doesn't error but doesn't do anything. It would be to feed back to the end user
whimboo: playwright does one thing different to use with display: contents
ACTION: Spec to be updated to throw an error for display:none
ACTION: whimboo to write a new issue for display:contents with test case and bring it back to the WG
Clarify how the double (triple) click tracking should work in the actions
github: w3c/
whimboo: this is another issue for actions. I have been checking different frameworks
… and they do things different ways for solving this e.g. in same chain or different chains
… so we should solve this to only allow in chain or not especially since separate chains could be tricky to see what people mean
jgraham: do we know what existing implementations are doing here? if I were building this this myself it would be in the same chain especially around network latency
… I am happy for state to be cancelled at the end of the chain but that might require client changes and that would be problematic
sadym: there is a potential if the user wants to do 2 single clicks. THey will have to wait a certain time accoridng to the OS
… so we need to be aware of how that plays out
simons: I think most clients would do the right thing here in a single chain. I quite like jgraham's suggestion here of cancelling state at the end of the chain
<jgraham> (I should say I don't know how easy that is to implement)
orkon: how would we specify this behaviour in the spec? Do we want to improve how events are specified?
jgraham: from the spec point of view. It is quite reasonable for the event must not have the double click attr have it set unless it's part of the action chain and the previous item was a pointer down?
orkon: I think the complexity is from there being a new event not just another click
… and it can be challenging for the event to be doing the right order
… if we don't have a "it must not have" we are making our own rules here
whimboo: one more comment to jgraham is that it's not only related to the time but it's also about the location of the mouse. E.g. a click, move 1 px, click won't be seen as double click even if it takes the same time as click, click
consensus: we are going to have double clicks in a single chain and clear state at the end of the chain. Also need to check if this might break clients
Should navigables created and navigated via WebDriver BiDi commands be counted as script-closable
github: w3c/
orkon; navigables can be closable which means scripts can do window.close
… there is also should be differences between browsers
… I think we should move away from html but do what we know users are expecting
jgraham: I think I agree with the conclusion here that we should do the same as if you are creating a new tab
… and that html isn't expecting the script closable flag to apply to user created top-level traversables and we should make these things unambiguously not script closable
<simons> I also need to leave
Support for "userContexts" argument to "browsingContext.setViewport" command
github: w3c/
Alexandra: Would be good to have pre-setup viewports for all browsing contexts. I sketched a proposal for this. There was some concerns on the design. I thought it would be good to bring it here for discussion.
orkon: Still need to review the PR on our side. It affects open navigables. That's a side effect. I guess it's not a big concern but maybe we should clarify whether we should activate, etc.
… I don't think it's a big concern, it seems fine to proceed.
jgraham: If it seems fine, let's do it. On the general conversation on attaching user contexts, you can already do that one context at a time.
… I don't think it's making anything new in that case, just making things easier when there are many browsing contexts.
… Useful for when running multiple tests with a given context, e.g., in mobile mode, etc. That helps set things up initially, and not having to worry about that at runtime.
sadym: I wonder how we will specify what happens when a new browsing context is created. We'll have a viewport for it. Do we have a hook?
sasha: Another good topic to discuss. Roughly the moment when we detect the round creation. Pretty early when we have the contextcreated event.
… Ideally, we would have a hook for that.
… Early enough, but not sure exactly when.
… If people have additional feedback on when that should happen, let me know. I'll draft something for further discussion.
jgraham: It should probably be tied to document creation.
… I need to look into details.
… Otherwise we could actually update HTML.
… I suspect it's not observable.
Geolocation emulation
github: w3c/
sacha: We would need to pick it up to work on it. Some discussion at TPAC on whether to move things here or in Geolocation spec. It would be good to clarify so we can work on it.
jgraham: I think we should consider pulling this stuff in our spec.
… Extending WebDriver BiDi is good, but it has trade-offs that makes it harder to refactor things afterwards.
… We know that emulation is a good feature that we want to have in BiDi and that it's a good idea to have alignment on a model for that.
… I think there's a demand for such features, easiest way to make progress for me is to work on them here.
… Of course, if Geolocation folks want to continue to work on this on their own, that's fine.
orkon: A middle-ground here would be useful. Perhaps it makes sense if Geolocation spec provides some mechanism but then CDDL and wiring remains on our side.
… I didn't review the draft. If it's already good and Geolocation editors want to maintain it, that's good.
jgraham: We want the actual hooks and algorithms to exist in the spec, I agree.
… We should talk to Geolocation people, ping that PR. If they can land the hook, we can work on the underlying bits.
… We don't want to maintain the details of how Geolocation works.
sasha: That sounds good to me. I think we have agreement.
… Follow-up question is where to put it in our modules. It could be in browsingContext but maybe something more modular. Thoughts on this?
jgraham: I think we should start the emulation module when we add the ability to add to userContext. browsingContext.setViewport. It's just about organizing things nicely.
… There's a bunch of things that we believe that we will have here, e.g., locale override.
… There's a fairly consistent API that we could end up with.
… Pretending that you are a mobile device, in a different timezone, etc.
<jimevans> +1 to what jgraham said. "emulation" module for the win.
orkon: An emulation module sounds good. In CDP, there's a problem of the domain. For BiDi, it makes sense to be able to define an alias for commands so that we don't have to duplicate things.
jgraham: I think we can do that to a very large extent without anything new.
… "This command uses the parameters from this other place".
… I think we can make a very small wrapper.
<jgraham> RRSAgent: make minutes
<jgraham> RRSAgent: make minutes