Meeting minutes
Action items from previous meeting
Rob to follow up on w3c/
Rob: CSS WG has a bot that files minutes to issues, can we have that?
Patrick: I'll ask PLH
context of the action was https://
mustaq: didn't we say we'd explore other avenues other than PE? i might be misremembering
Patrick: we already decided that we'd defer this to future, not cramming into v3, so no major rush
https://
[Group discusses again the intricacies of new handwriting touch-action, and where this new value would need to be assumed to be included, and other cases where authors will have to explicitly add it, e.g. when they explicitly defined a touch-action for pan-x but they now ALSO want handwriting, but in other cases it has to be assumed like for touch-action: none]
Patrick: can we add something to w3c/
ACTION: Rob to add a small reminder (to ourselves, mainly) what our current thinking/challenges are for w3c/
Patrick: other action we had was - Group to review w3c/
mustaq: on the outstanding comment from Rob - think we want to call out primary pointer mainly because no implementation does hover for anything other than primary
Rob: seems strange that you get boundary updates for one finger rather than ohters
mustaq: wanted to maintain what UI Events spec does ... at least my interpretation. this calculation is expensive, so i think that's the rationale for calling out primary, since that's also only one that hovers. i can open a new issue separately, or we can work still on this PR
Rob: with this PR we match mouseover/mouseout behaviour for the primary pointer event
Rob: UI Events talks about mouse, and then introduces primary pointer...which is confusing
Rob: maybe we limit this to cases where you only have one active pointer, which is the primary pointer of the current type
Rob: primary touch is only primary while there's only one touch?
mustaq: you mouse hovering element A, you tap element B. does the mouse jump? on some implementations it does, on others the mouse pointer disappears
Rob: i think the visible movement of mouse is a legacy from older touch devices...
Patrick: that's more a visual UI thing left up to UAs, not something that concerns us anyway. the "disappeared" mouse pointer moves to where your touch was, and when you wiggle the mouse again the UA decides to either start from that touch position, or from the previously known mouse position (?)
Rob: we might only be able to do this for devices that DON'T have implicit capture
Rob: hover effect is only caused by the legacy mouse pointer. because touch has implicit capture, maybe we don't need to worry as you can't change the target underneath it... (?)
Rob: ... unless you removed capture, which I think you can do / release
Rob: which is going to be an edge case
mustaq: i think implicit capture is the only one that makes the distinction....
<flackr> https://
Rob: you raised performance, but if we assume that a captured pointer doesn't change its target, we don't need to worry about it...so performance hit only for edge case?
Rob: we can remove that whole active pointer requirement, and have no perf hit, because most times pointers will be captured
mustaq: so I should remove the primary condition bit
mustaq: do we need to discuss further, or we settled
Rob: to make everything nice and consistent, this seems to make sense
mustaq: there was also a comment from masayuki, but that's a separate issue. he approved the PR, so we can leave that for another issue
ACTION: mustaq to remove "primary" from w3c/
Clarify that click, auxclick and contextmenu get their .button and .buttons behavior from UIEvents w3c/pointerevents#531
mustaq: approve that an hour ago, looks good to me
Patrick: I'll massage the wording slightly and then merge
ACTION: Patrick to tweak and merge w3c/
Implicit pointer capture state after a failed explicit capture call at pointerdown w3c/pointerevents#534
mustaq: implict pointer capture is set by browser, and author can then release or set different capture. what happens if this JS by the author fails?
Rob: what happens now in general when second capture doesn't work/calls it twice?
mustaq: then only the first one "takes"
Rob: so seems consistent
mustaq: will check if WPT covers this already, if it does i'll close issue, otherwise will comment there and keep open
ACTION: mustaq to review w3c/
Define pointermove and pointerrawupdate may have delta from previous corresponding pointer event as movementX and movementY w3c/pointerevents#535
mustaq: looks reasonable
Rob: yes
Patrick: so question - do we want this in v3 or defer. how easy/hard is it to add to our spec? looks like it might involve a lot of extra writing and defining new things
mustaq: think we don't even mention movementX/movementY in PE spec. so this looks like it'd need a lot of work - ripping it out of mouse event spec
Rob: not even in mouse event spec, it's an extension to pointer lock spec
Rob: seems like pointer lock could/should extend pointer event, rather than other way around
Rob: in the linked section https://
Rob: so if pointerlock extended PointerEvent rather than MouseEvent, this would be handled for free
Rob: pointerevents extend mousevents, but yes it should be defined/mentioned in pointerlock, not in pointervents spec
mustaq: so we should open an issue against pointerlock, and close the issue at our end?
Rob: sounds reasonable
ACTION: mustaq to close/move w3c/
Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445
Patrick: I think nominally we only have one that needs WPT https://
mustaq: this sounds tricky ... related to what we just discussed with pointerlock...
[discussion on what happens in chrome with dom event change signalling that target needs to be recalculated. might not happen for the events dispatched already in the current tick]
Rob: want to avoid needing to continuously do hit tests
mustaq: the ancestor checking couldn't be shipped in chrome due to interop...
Rob: interop issue not in Firefox though, so it's something in Chrome's implementation
mustaq: it was some shadow DOM behaviour
Patrick: so is this realistically something we can look at for v3?
Rob: we could test state we're currently in - does target change for the move for pointerevents, mousevents, ... if you modify the DOM in events that are synchronously part of the same event stream
Rob: might be a similar question ... maybe with focus, or similar UI events, that have a similar problem
Patrick: so something that can be explored for next time?
Rob: pointerrawupdate i thought the point was that we determine the target from the last non-raw update
mustaq: because the last raw event may NOT be coalesced
Rob: does it do a hit test, or take target from the last move?
mustaq: so it "seems" to be v3 blocking
Rob: doesn't introduce a new feature, relates to accurately describing current spec behaviour
ACTION: for next meeting, review w3c/
Olli's webcompat issue https://bugzilla.mozilla.org/show_bug.cgi?id=1943411
Rob: this is the thing we just discussed
"Masayuki and others analyzed that and he then wrote a patch which mimics Chrome Canary's behavior.
Release Chrome does something a tiny bit different, I think either the test for mousemove or for the pointer events fail there.
Tests are in https://
I don't think the specs define too accurately what the behavior should be."
<mustaq> Mozilla change: https://
Rob: my intuition is that at the point we generate enter event, we already determined the target of the move
Rob: pretty sure for enter event we dispatch it to the removed node
Rob: we could dispatch to the removed node even though you're not supposed to do that (?)
Rob: ... this is all part of the same problem - we assume that the DOM doesn't change in between these events
Rob: not a terrible assumption..
Patrick: apologies, we're over time and i hadn't realised. thank you as ever, catch you in two weeks' time