W3C

- DRAFT -

PEWG

02 Jun 2016

Attendees

Present
NavidZ, Mustaq_Ahmed, Rick_Byers, smaug, Dave_Tapuska, Dave_tapuska, teddink, Scott_Gonzalez, shepazu, mbrubeck
Regrets
Chair
patrick_h_lauke
Scribe
patrick_h_lauke

Contents


<scribe> scribe: patrick_h_lauke

Should pointer IDs be unique even across different top-level browsing contexts?

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

Support hovering button states https://github.com/w3c/pointerevents/issues/14

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

Spec implies lost/gotpointercapture is delayed until the next pointer

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

Summary of Action Items

Summary of Resolutions

  1. add a note to spec - RICK
  2. comment to be added to github issue for feedback
  3. Ted to find out more info
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.147 (CVS log)
$Date: 2016/03/23 18:03:34 $