Meeting minutes
hmmm...can't seem to start the meeting
in zoom i mean
<smaug> ah, you're not the host?
suspect it's because Philippe is still the host
<mustaq> I am seeing "Waiting for host to start the meeting"
<flackr> should we use an alternative for today?
ok, quick change of plan...firing up a separate zoom. please hold
snap
https://
Meta-issue: update WPT to cover Pointer Events Level 3 w3c/pointerevents#445
Go over https://
Patrick: so how are we doing with the WPTs?
Olli: it's going down. think it was 10-11 last time
Olli: I closed one, Edgar closed one
Mustaq: I closed one, and have one waiting for review
Olli: added a comment to the one about secure context
Olli: that's something we probably need to change. would be risky right now to hide the whole method, instead we could always expose the same event as the real event
<mustaq> w3c/
Mustaq: agree it's risky, don't think we have a counter. not sure how many sites rely on this. probably just returning empty list would be ok
Olli: not thinking empty list, it should always have one, so just send a copy of the same parent event
Olli: so we'd need to change the spec a tiny bit
Olli: worried some libraries might already rely on this, but don't have any data.
Mustaq: think we can go for it
Olli: issue filed for this here w3c/
Rob: wouldn't want to change things until we have data
Rob: APIs have been around for a long time, so best to wait for data
Olli: what i'm suggesting would not break API though, it just returns a single item list
Mustaq: if we can count how many times getCoalescedEvent gets called in a non-secure context, we can switch it over
Rob: if we had the data to suggest that this isn't being used from non-secure context, we should remove the method. would be less surprising
Olli: but if the API doesn't break, just that it only returns a single item...
[discussion on whether we want to wait for data or not]
Patrick: i'd suggest going for the "simpler" approach that Olli suggested - keep method/API, but clarify that the list only contains a single CLONE of the parent event
Patrick: but also gather data, then we can in future think about removing the method altogether in non-secure context if data shows that nobody's using it in those cases
ACTION: Patrick to look at #472 and propose PR to clarify what happens in non-secure contexts (only returns a list with single item, CLONE of parent)
Olli: was also trying to look at w3c/
Mustaq: I landed a change, by end of today you should be able to test it
<mustaq> It is an automated test now.
Patrick: so let's carry on with this. will send reminder a week before next meeting
Heartbeat: Clarify what the target of the click event should be after capturing pointer events w3c/pointerevents#356
Patrick: since last meeting, I spent some time visually highlighting the outlier results in w3c/
either
[looking at what we decided last time]
Patrick: minutes from last time https://
[more discussion on what we went over previously]
Mustaq: ... most recent discussion was about async click...
Patrick: minutes from two meetings ago has more of our thinking at the time https://
Rob: ...click event is not meant to be separately targeted, so should not be different from the up event... do the computation of what click target should be at the point where we do the up event...
Mustaq: challenge is that lostpointercapture has been fired, but then forcing click to go to what was captured before (and click going to blue)
Olli: ...what happens to the mouseup - i know it's legacy, but still used...
Olli: what is the target of that if pointerup explicitly releases
Mustaq: with mouse it's easier, because everything is synchronous
Olli: just wondering what the behaviour here should be though
Olli: may also need to add mousedown/mouseup, as some of the behaviour we see may be related to these legacy events
Rob: also don't want to forget what author/developer expectation would be when using pointer capture
Patrick: i guess as developer, i wouldn't care about where the mouseup happens if i'm capturing... but i think what we're getting at is that the need to create legacy mouse events MAY be the root cause of this weirdness, since we didn't spec it so precisely ourselves.
ACTION: Extend the test codepen to also include mousedown/mouseup, rerun results
ACTION: before next meeting, will send email reminding everybody to COME PREPARED with their own take of what the best/most reasonable way forward here is
Rob: related, do we know of any major sites using pointer capture?
Patrick: I often feel no real-world developer out there is making heavy use of pointerevents, though now pleased to see sessions from latest Apple event consistently now using pointerevents
Mustaq: I have vague memories of some side-scrolling game using it...
Rob: more interesting then as well - how many sites are using capture AND are then hot-swapping the element that has capture, i guess not many
Rob: let's do a detailed session next time about this
<mustaq> w3c/
spec doesn't match WPTs #303
Mustaq: railing behaviour in WPT - once scroll starts, Chrome tries to latch onto that direction...
Mustaq: [explains current behaviour in Chrome, which passes the WPT, but all other browsers fail?]
[discussion on what current behaviour in Chrome is...that the browser can take over in the course of an ongoing gesture]
Mustaq: the test was done a long time ago, legacy behaviour
Patrick: i'd say most sensible would be to change the test and Chrome's legacy behaviour, and make sure our spec is clear about ONGOING gestures
Rob: [mentions the "slop" and the point at which a developer could safely assume whether the browser is scrolling or if they now have control over that gesture]
Mustaq: at some point (?) we had the philosophy that browser could take over at any point even for ongoing gestures
Mustaq: definition of "slop" is not in the spec
Rob: but it's developer-observable. move fires at the point where you exceed the slop region
Olli: do you happen to have a test case for all this (not necessarily WPT, just anywhere)
Mustaq: we have quite a few tests in WPT
Rob: you can look at the cancelable flag on the move event, and you can tell from that whether it started to scroll
Rob: once we start a scroll it's no longer cancelable
Olli: spec says pointermove is always cancelable
<mustaq> https://
Patrick: but no pointermoves are sent when scrolling starts
Rob: but on that last event before it scrolls...
Rob: how can dev tell in their pointer handler that browser took over scrolling
[more discussion]
Rob: going back to initial issue, we should make sure that only initial direction is used, and browser does not decide during an ongoing gesture to jump back in and take over scrolling
Patrick: agree, change WPT accordingly, make sure spec is explicit about it, and then change chrome behaviour
Rob: do we know any sites that rely on this particular behaviour, if it only happens in Chrome
ACTION: test #303 not in webdriver (which has potential bugs), but in real browser
Rob: one more point against current behaviour is the asymmetry of the behaviour...