Pointer Events Working Group Voice Conference -- 16 Jun 2015

<scribe> ScribeNick: ArtB

<scribe> Scribe: ArtB

Tweak and agree on agenda

AB: I posted a draft agenda yesterday https://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0111.html. It includes quite a few topics but I think some of them might go quickly. Any change requests?

RB: can drop #5

… think we covered it on the list

AB: we can take it in order and then drop it

<rbyers> test now

Hover click with pointer events

<rbyers> any better?

<scott_gonzalez> yes

<patrick_h_lauke> rbyers yes think so

AB: Timothy sent this e-mail to the list on April 22 https://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0080.html and Patrick replied yesterday https://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0112.html voicing support.
... if there is agreement to add this feature, then we need a PR or an Editor can take the lead and commit text.

<rbyers> crap

AB: Tim, Patrick, any comments?

PL: agree in principle would be good to have

TD: think we need some more text

<jrossi> had technical difficulties, but i'm here now

<jrossi> is the call working?

<jrossi> i'm on but don't hear anyone

RB: not clear how to update the spec for this

… think we need PRs and then discuss them

MA: think we need more text to cover this

<rbyers> Yes, let's discuss the specific spec impact

<patrick_h_lauke> i think there are two aspects to this from my point of view

AB: so I think Rick is asking for a proposal and/or PR. Is that correct Rick?

<rbyers> I think Mustaq was saying there are expections in the spec that may be violated by changing this

<patrick_h_lauke> a) do we open up the possibility that button/buttons is changed even when stylus is hovering

<patrick_h_lauke> (which it currently doesn't, at least on surface 3 + surface pen)

<patrick_h_lauke> b) whether we then also want to differentiate hovering pen vs touching pen

<patrick_h_lauke> +1 audio quality is...sub-par

<mustaq> I was trying to say: we have events for change-of-stylus-state w.r.t. touch surface...

AB: I think we need more discussion and proposals

<mustaq> but in this case we need events for button state changes.

<mustaq> like buttonchange?

<patrick_h_lauke> hmm, so that's perhaps even a third point

TD: I agree with following up on the list

<patrick_h_lauke> c) firing an event when button state changes

AB: ok, let's do that

Non-scroll-blocking wheel events listeners / relationship to PEWG?

AB: Rick continued this thread on April 22 https://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0081.html. Is there a specific Action and/or Issue(s) to record?

<scott_gonzalez> The spec says that you get a pointermove event if the buttons change.

<scott_gonzalez> "Additionally, when a pointer changes button state, pressure, tilt, or contact geometry (e.g. width and height) and the circumstances produce no other pointer events defined in this specification then a user agent must fire a pointer event named pointermove."

<patrick_h_lauke> scott ah, good point...forgot

RB: the big picture here is we are seeing cases where blocking event handlers are bad for perf

… have probs f.ex. wheel cases

… need to address wheel events and touch events

… not clear which group is the best place to have this discussion

… could be www-dom or public-touchevents

… I'll make a proposal on Github

… and then we can decide on how to proceed

AB: that sounds GTM

JR: I'm ok with having this discussion in this group

… and getting discussion on GH is good too

… this is definitely an area of interest to us v-a-v Edge

RB: we had some discussion with Moz/Toronto

… they have a heuristic that works for them

… it could be a counter-proposal to my wheel proposal

JR: or perhaps can do both

RB: I'll include information about why this is important to solve

AB: that SGTM

Expected behavior when releasing a button after pointer capture

AB: Scott started this thread on April 27 https://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0089.html. Rick's last reply seems to imply a change is needed https://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0092.html i.e. it appears a concrete proposal (PR) would be useful.

[ Scott summarized the proposal ]

SG: Rick noted browsers are converging on this behavior for mouse events

RB: the history is complicated for mouse events

… not sure about the right answer

… we are doing some related compat testing

… can argue we need mouse and pe event compat

… We need implementation feedback to guide the design

SG: you mentioned FF is changing and Chrome is changing too

RB: both WK and Chrome do not fire events continuously during a scroll

<scott_gonzalez> http://dev-test.nemikor.com/behavior/mouseover-when-element-is-shown.html

SG: not sure if FF uses heuristic to prevent their behavior

RB: we need to be consistent with mouse events

… but we might want to also define the most rational thing for PE events (regardless of mouse events)

JR: think we need to be careful to change things just for one scenario (scrolling, animations, layout)

… haven't seen issues without having this behavior today

… I'm not particularly alamed by our behavior to change it

… but if I am missing some compat issues, then would be good to know

RB: mouse cursor is an interesting scenario

… we have a hack with a timer that updates mouse cursor

… what does IE do?

JR: not sure off the top-of-my-head

[ Jacob talks about IE implementation details ]

JR: if you have some impl feedback here, please share that info

<rbyers> Here's the main one: http://crbug.com/26723

AB: perhaps we should record an issue so we don't loose track of this

JR: sure

… would expect this to be tricky for us to implement

RB: there is definitely a potential performance hit

JR: yes, agree there is a potential performance implication

<rbyers> Big picture issue that covers the whole space here: http://crbug.com/488886

… therefore we need to know for sure there is a compelling compat issue that needs to be solved

SG: in general, yes I can see lots of changes might be needed

… but if just loosing pointer-capture, that's just one case

JR: I think the consequences could be broad for us

RB: think the changes for Chrome would be more incremental

… FF almost always updates the hover state

… IE only does the update if cursor moves

… and Chrome is somewhat in the middle

<scott_gonzalez> This is the oldest ticket I can find related to this: https://bugzilla.mozilla.org/show_bug.cgi?id=20022

AB: would you Scott please create a GH Issue?

SG: yes

Capture semantics for a node that moves between documents

AB: Rick started this thread on April 30 https://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0095.html. Scott cited text that appears to address Rick's question so not clear if this is a NOP or if some additional text would be helpful.

RB: I agree; let's move on

SG: lots of implementation diffs here

… f.ex. with replaceNode

RB: if there are related issues f.ex. in jQuery, please do let us know

Correcting inverted pan direction definition

AB: on May 8 Rick committed a correction re the pan direction definition https://lists.w3.org/Archives/Public/public-pointer-events/2015AprJun/0100.html (commit https://github.com/w3c/pointerevents/commit/8548506a7db4de67fa6b8ca997887fdb6a0c8056). Any comments?

<jrossi> LGTM

AB: any other comments?

Bugs and Issues

AB: there is one open Bugzilla bug http://tinyurl.com/Bugs-PointerEvents and a few open Issues https://github.com/w3c/pointerevents/issues.
... Do we want to discuss any of these today or expect discussion to continue online (i.e. the list, Bugzilla and/or Github)?

JR: no

RB: no

AB: so everyone, please provide feedback

Implementation status

AB: any updates on implementation?

AV: Matt isn't here today re FireFox

<jrossi> new implementation: Microsoft Edge :-)

… so let's get that input next time

<jrossi> ;-)

DS: is the Edge mostly the same as IE impl?

JR: mostly the same; some bug fixes

<patrick_h_lauke> forgot where we stood with it, but: what are we doing about the event order / simplified model that Edge uses?

RB: we are actively landing patches

… Mustaq has patches

… still quite far from doing everything we need to do

JR: is there a flag yet?

RB: there is a flag in Canary

… have the basic support in JavaScript

AB: great

RB: just a command line flag now

<rbyers> --enable-blink-features=PointerEvent

AV: which features are supported

RB: create and dispatch events now

… some p-up and p-down support

… no leave yet and other stuff missing

… can follow the status via a Chrome bug

<rbyers> Top level chrome bug: http://crbug.com/471824

AB: thanks for the updates

AoB

AB: any other topics for today

JR: there are some issues with test library

… need some new test cases

<rbyers> Firing pointer events for touch input is the main thing Mustaq is working on now. http://crbug.com/476565

… we plan to contribute them back and will ask for review

<mustaq> In canary, the --enable-blink-features=PointerEvent flag makes PEs visible.

<jrossi> yes it's pretty cool

SG: we pull in w3c test suite and pull them in with WebDriver

<jrossi> https://github.com/jquery/pep

RB: want to talk about how to make the test more automated

DS: good; we need to do that across other groups too

SG: if there is a missing test, we will write it and automate it with WD

RB: are there some manual instructions too?

SG: we are loading the test as is and then feeds the assertion back

… and define WD steps in a separate file

<scott_gonzalez> https://github.com/jquery/PEP/blob/master/tests/functional/pointerevent_button_attribute_mouse-manual.js

<jrossi> https://github.com/theintern/recorder

RB: we need to do something like this too

… thus seems like we need to share these files

DS: yes, make them part of the harness

SG: agree; that's why I mentioned this topic

RB: definitely want to get more automation of w3c tests

DS: seems like we need to broaden the scope of the discussion

… since this isn't just PE specific

… I can set up a meeting

… Scott, is there a document about what you are doing?

SG: no; but we can create something

JR: agree this is important

… WebDriver needs more APIs then the basic features supported now

… especially for touch and pointer events

… think they need to do more work before we use WD directly for our scenarios

RB: yes, we would be interested in a common way to do this

AB: so Doug, are you volunteering to start a thread or have a call

DS: yes

<jrossi> raises hand

… who is interested?

RB: me

SG: me

JR: me

AB: me

<asir> me too

… I think public-test-infra would be a place to start

… MikeSmith might know the WD driver list

<rbyers> WebDriver spec says public-browser-tools-testing@w3.org

<rbyers> https://w3c.github.io/webdriver/webdriver-spec.html

<jrossi> sure, something predictable would be nice rather than ad hoc

AB: what about call frequency?

<rbyers> monthly sounds good to me

<rbyers> we can add more if necessary

AV: something predictable would be good and then cancel if necessary

<rbyers> sorry need to drop off

<mbrubeck> I'll just add on IRC that we enabled Pointer Events in Firefox Nightly a little while ago, found some bugs and disabled it, but should be ready to re-enable it in the next few days.

AB: Matt, that's great; thanks for this info!

<scott_gonzalez> https://github.com/jquery/PEP/blob/master/tests/intern.js#L6-L10

AB: meeting adjourned

<asir> Thank you for sharing the info Matt! Great!

- DRAFT -

Pointer Events Working Group Voice Conference

16 Jun 2015

Attendees

Contents