<scribe> scribe: patrick_h_lauke
https://github.com/w3c/pointerevents/issues/59
Ted: sorry, dropped off my radar
... it's currently handled by a higher-level broker, so not directly in Edge
Rick: our concern is that it can't likely be implemented on all platforms if it's platform-specific
... so it's a potential interop issue. Question for ted: are there scenarios where this is crucial, like drag'n'drop across windows. is there anything that would break in Edge if ID was NOT consistent across windows
Ted: from D'n'D perspective i don't think so, because of how it's implemented under covers / interaction with OS and broker/container
broker handles all hand-offs of pointer and d'n'd integration
whether any developer is currently relying on it? doubt it, didn't have inter-window d'n'd until recently, so doubt there are web devs relying on this behavior
still worth for us (me) dig in a little more to verify what behavior we're seeing especially in cross-window scenario, if IDs are consistent or changing
Rick: we may want to put note in spec saying that they're NOT guaranteed to be consistent across windows
do we want to make IDs explicitly random so devs definitely don't think that there's consistency
thinking of scenarios where a framework may want to do this. open a popup window and communicate via postmessage, and they're sharing info / coordinating input. for ex. google feedback provides feedback on a google prop. uses iframes but could conceivable use popups
wondering if there are more scenarios like that where devs would expect IDs to be consistent
Ted: only way to be consistent would be if it was pressed DOWN consistently, as IDs can change
so would only work if people dragged between windows. also dragging into iframes, but we don't currently support it
Rick: so should we call this out in the spec, and note that Chrome/Edge have difference in implementation
RESOLUTION: add a note to spec - RICK
Navid: why not just use pointermove for all changes?
<smaug> you get pointerdown/up for button changes
<smaug> ?
Navid: the worry is if pointer turns into active button state
<smaug> click fires for left button only, but down/up for all
Navid: currently pointermove fires for all changes, but does the pointer turn active when hovering and buttons pressed?
Rick: for stylus, only active when touching digitizer
Mustaq: maybe we need to clarify - for hovering button press, you DON'T see a pointerdown; you see a pointermove with updated buttons; but pointer does NOT become active
Ted: it feels very consistent to me, echoing Rick's point keeping it simple and consistent
oops sorry...i'm terrible with voice recognition
<smaug> click is special
Rick: the problem is what happens when pressing buttons over an element while hovering. is it intentional manipulation?
developer who cares would write their own behavior
Oli (?): click is special though
has special behaviors / rules
Navid: [missed] make special case for primary?
Rick: Ted, hovering stylus with button clicks doesn't normally action/activate things?
... we may need to special case what it means for a stylus to be active
Ted: we should also keep in mind hovering touch scenarios
Mustaq: but it's different because you don't have a button that signifies an action/click in mid-air for touch
Ted: unless somebody implements some kind of gesture that is interpreted as a click
... pointermove indicates state change, but no pointerdown/pointerup until stylus touches screen
<dtapuska> mustaq: What about activation button state
(shepazu: rrsagent didn't join the channel despite being summoned with the right incantation)
Scott: but current spec doesn't allow for a change of buttons without a pointerdown (?)
Rick: spec is simpler if we don't add any further behavior (?)
<rbyers> Scott is arguing that the spec is simpler and easier to understand if we don't special-case stylus here. A hovering button press is just like a right-mouse-button press.
<rbyers> And less confusing to developers
<scott_gonzalez> Correct. And you can already detect a hovering click by looking at the buttons property.
Mustaq: we don't send click for any non-primary pointers, so change spec to also say not for hovering stylus
(sorry having hard time following conversation here)
Scott: we currently treat barrel press on hovering as nothing, only on contact
Rick: we could fix as scott suggests by fixing the chorded buttons section
Ted: so you could have the different states for barrel button, contact, and barrel + contact with different values
Rick: and Edge's behavior can still be per spec if hardware does not detect/support
Mustaq: button and buttons property has contact as condition...that's the problem
Rick: yes, if we go with Scott's proposal we remove that, it's simpler
is it real concern that users press barrel button by accident when hovering?
<dtapuska> some of this conversation relies on this proposal https://discourse.wicg.io/t/new-event-for-non-primary-button-click/1527 (to fire only the click event on primary button)
Ted: let's write up the proposed solutions in github issue and i'll check with Jacob
Scott: only feedback found when looking for "hovering barrel button" was an issue of user complaining about autohiding task bar not appearing when hovering over bottom of screen...so seems low risk
as we're talking about NOT special casing hovering stylus, so this feedback supports it (treating it like a mouse)
as soon as device knows it's there it's treated like a mouse
Ted: suspicion is in windows if they swiped up from bezel, the taskbar would appear. windows likely treating it a bit like touch which has no hover
Scott: in touch we don't have buttons, so any activation is contact. but with stylus we can have button even without contact, so contact is not purely synonimous with activation
treat stylus tip like a button in its own right
<rbyers> Mustaq: what if both primary and barrel button are down when the pen contacts the screen?
<rbyers> Navid: would be as if the button changes happened outside the window - get pointerenter and no pointerdown
<rbyers> Scott: if you're hovering when you press the button you'd get pointerdown then
<rbyers> Mustaq: Yes, I Agree - was talking about devices that have no hover ability
<rbyers> Scott: would get pointerdown - property change caused buttons to go from 0 to non-zero
Scott: if barrel button is pressed for stylus that doesn't support hover in mid air and then you touch screen, you'd get pointerdown with the relevant button/buttons
<rbyers> Mustaq: we all agree on 'buttons' but what about 'button'?
<rbyers> Scott: expect it to be the primary pointer, it's the state change that causes the event to be fired
<rbyers> Mustaq: ok - current wording seems good enough
<rbyers> Dtapuska: what if you press barrel button, then contact digitizer, then lift off digitizer and make contact again
<rbyers> Scott: on recontact, buttons would be 1 if not holding barrel button, 3 if you were
(I think i have to make a demo to visualise button/buttons for my own sanity to then test with Surface 3/Stylus)
<rbyers> Navid: so can we add this proposal to the issue?
Ted: in general, no concerns with these points discussed so far, but will be good to see proposal
RESOLUTION: comment to be added to github issue for feedback
not PRing just yet
event but Edge does otherwise https://github.com/w3c/pointerevents/issues/32
Ted: spent most of day yesterday on issue, got few loose ends to tie up to check our implementation
today there's no delay
Mustaq: the problem comes when pointer ping/pongs between two elements
can end up crashing unless there's a delay. so we'd like to know if there's a heuristic at play
Ted: there may be some esotheric details, debouncing, working on it
RESOLUTION: Ted to find out more info