Meeting minutes
<smaug> a bit late. coming...
Philippe: I realised that we're late with the charter, working on renewing this now
Philippe: are we all ready for TPAC?
Patrick: i'm all booked, who else is going?
Rob: I've not booked, I wasn't going to join...
<mustaq> I am planning to join virtually
Meta-issue: update WPT to cover Pointer Events Level 3 w3c/pointerevents#445
Go over https://
Olli: was trying to write a test for coalesced/predicted, but it looks like we need manual test - can't get it with web driver it seems. issues dispatching events to target not in the DOM. other issues running the harness for manual tests. I'll continue
Philippe: when you say it wasn't working in web driver, is it lack of support?
Olli: it's supported in Chrome, but not Firefox...
Philippe: but it is supported in web driver?
Rob: but it's not specific to web driver. we can potentially add it to web driver
Philippe: do we have an issue against web driver?
Rob/Olli: we should yes
Rob: question is whether you're testing the right things. if you pass in data to web driver for predicted events, you're not testing how the platform itself populates predicted events...but we can still get something going
Olli: i'll file an issue
Mustaq: I think I closed 1-2 issues for WPT
Mustaq: i looked at w3c/
Olli: if you open a new window...
Mustaq: does test harness allow it/work with a new window?
<mustaq> w3c/
Rob: if you have out of process frames, would those not be equivalent to top level context ?
Mustaq: spec-wise is it same as top level context or no?
Rob: I think it has to be
Olli: cross-origin iframes...they can't be top level?
Rob: but they can't know anything about other contexts, so effectively they are...
Olli: you can still pass messages/have a relationship
Mustaq: let me try to see if that works
Mustaq: "the pointerId MUST only be associated explicitly with that particular pointing device for the lifetime of the page / session" but this must is conditional, so should i test?
Rob: "and a new randomized pointerId MUST be chosen the next time that particular pointing device is used again in a new session" that sounds testable to me
Mustaq: my point is the MUST is conditional on the previous para, which is a MAY, so should i spend time to test this?
"The user agent MAY recycle previously retired values for pointerId from previous active pointers, or it MAY always reuse the same pointerId for a particular pointing device (for instance, to uniquely identify particular pen/stylus inputs from a specific user in a multi-user collaborative application)."
Mustaq: so the two MUSTs are conditional to the second MAY
Rob: in theory testable, but don't think we have infrastructure to test. you need something that has consistent id, which touch does not
Mustaq: in chrome
Rob: you'd start testing the MAY part. if that is true, then spin up another frame, and test if it's a different id
Rob: it is testable though
Olli: it is testable, so we should test it
Mustaq: mouse we can test, as mouse is always consistent. touch, id changes in chrome and firefox...
Rob: you can't test a drag/movement, as there's capture
Mustaq: is condition true for ANY browser though?
Rob: it is true for certain devices, but don't think it will apply to touch...
Olli: emulation might
Rob: stylus might, as there's desire for strong association from one touch to the next
Olli: devtools doesn't properly reflect real device here
Olli: third test...secure context... did we have a resolution?
Patrick: i owe you a PR, from actions/minutes from last time
Olli: that we returned a clone of sorts...
Patrick: here's the action from last meeting https://
PAtrick: the discussion here https://
Patrick: so I'll carve some time out and do a PR for you to check
ACTION: PHL to write PR for https://
Patrick: so the old PRs that still have tthe "needs-wpt" label https://
Patrick: some of these we already talked about just now
Clarify pointerleave and pointerout events when first pointer move after removing an element under the pointer w3c/pointerevents#477
Mustaq: need time to dig into this further
Patrick: do we think it's v3 blocking? i've set as such for now
Olli: this actually might be....
Mustaq: my understanding is that the DOM event dispatch algo doesn't mention modifying DOM, so some things become undefined
Mustaq: could somebody check if the DOM event spec says anything about DOM modification?
Olli: DOM event dispatch should not be affected by DOM modification, as path is stored when event gets dispatched. so path is still there even if the DOM gets modified in flight
Olli: this case here though is more about pointer events
Olli: all the browsers fail the test
Olli: don't know if they're failing in different ways though
Mustaq: it's on my interop list, so need to check this for sure
Olli: need to review this more, need to figure out also for interop
ACTION: investigate w3c/