On Wed, Dec 14, 2022 at 4:28 PM Sahir Vellani <sahir.vell...@microsoft.com> wrote:
> > > ------------------------------ > *From:* Rick Byers <rby...@chromium.org> > *Sent:* Wednesday, December 14, 2022 1:05 PM > *To:* Ben Mathwig <benjamin.math...@microsoft.com> > *Cc:* blink-dev <blink-dev@chromium.org>; Mustaq Ahmed <mus...@google.com>; > fla...@chromium.org <fla...@chromium.org>; Sahir Vellani < > sahir.vell...@microsoft.com>; Ben Mathwig <benjamin.math...@microsoft.com> > *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Prototype: > PointerEvent.deviceId for Mult-Pen Inking > > You don't often get email from rby...@chromium.org. Learn why this is > important <https://aka.ms/LearnAboutSenderIdentification> > On Mon, Dec 12, 2022 at 1:07 PM 'Ben Mathwig' via blink-dev < > blink-dev@chromium.org> wrote: > > > --- > *Sahir & Ben: wondering why a new deviceId field seems more logical now > against the original proposal of repurposing the pointerId field? Is it > because of the compat concern you raised in w3c/pointerevents/issues/353 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fpointerevents%2Fissues%2F353%23issuecomment-1346776842&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579474144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=01VF%2FXH9E%2FAUhsZXbQhd4irjmMNlWxyIj9rYZcKDTwQ%3D&reserved=0>?* > --- > > The primary reason is the deterministic nature of deviceId compared to > pointerId. The scenario would be: (a) If the device supports getting a > unique hardware identifier, we randomly generate an integer and persist > that integer for the document lifespan. (b) If the device does not support > getting a unique hardware identifier, does pointerId fall back to its > original behavior? In the spec, we decided between null, undefined, and > integer as the deterministic values of deviceId. > > We *could* use pointerId instead, but we'd have to align on the solution > for (b) > > > I guess we should take this to a GitHub repo somewhere, but I can't help > but interject: sounds like a pretty good use case for > InputDeviceCapabilities > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FAPI%2FInputDeviceCapabilities&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579474144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HCNZsP13%2B%2FAfS3SWOWd9fbw79yXa3kFnWElJzq8VulU%3D&reserved=0> > to > me (i.e. 'hasDeterministicPointerId') ☺. Perhaps along with a boolean on > the event for the limitation case discussed in the explainer. > > TIL! Just so I understand this correctly, we would have something like: > event.sourceCapabilities.hasDeterministicPointerId as a check > to let the web developer know that the event.pointerId is a valid device > ID? > Yep. Jeffrey had made a similar suggestion about mitigating the potential > confusion of null/undefined by adding a separate boolean. > > Open to moving this discussion to the appropriate forum. > Filed https://github.com/WICG/input-device-capabilities/issues/43 for lack of a clearly better place. This also has the benefit of already being a WICG spec you could easily augment. But I'm biased, I'm the editor and still kinda sad we never had a reason to expand this beyond the one bool we added years ago the last time we had a pretty specific problem that I proposed a tiny extension to PointerEvents to solve. I forget who it was, but someone at the time argued for a separate extensible pattern like this rather than bolting onto another boolean onto PointerEvent. On Monday, December 12, 2022 at 8:08:11 AM UTC-8 Mustaq Ahmed wrote: > > Supporting consistent IDs for supported pens sounds great. > > Sahir & Ben: wondering why a new deviceId field seems more logical now > against the original proposal of repurposing the pointerId field? Is it > because of the compat concern you raised in w3c/pointerevents/issues/353 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fpointerevents%2Fissues%2F353%23issuecomment-1346776842&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579474144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=01VF%2FXH9E%2FAUhsZXbQhd4irjmMNlWxyIj9rYZcKDTwQ%3D&reserved=0> > ? > > > On Thu, Dec 8, 2022 at 5:16 PM Rick Byers <rby...@chromium.org> wrote: > > On Thu, Dec 8, 2022 at 1:17 PM Sahir Vellani <sahir....@microsoft.com> > wrote: > > Thank you for all the feedback! > > > > Rick, yes that’s correct. The ID will be refreshed on reload and iframes > will have a different ID to their parent/each other. Also, we can > definitely explore integration with web driver and adding a WPT test. > > > Perfect. I'm not a privacy reviewer, but that makes a lot of sense to me. > > Ben, any thoughts on the PEWG path Rick mentions below? > > > Sounds > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fpointerevents%2Fissues%2F353&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579474144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vh5oZuMKrcIaF5LaqSFGmQNFkhNrIxLE4c8O17TD%2B8s%3D&reserved=0> > like the current editor / WG chair prefers a WICG spec until L3 gets > finalized anyway. But knowing it's just a process thing and can trivially > be moved into the PE spec once L3 reaches REC seems good enough to me. > > Sahir > > > > *From:* Rick Byers <rby...@chromium.org> > *Sent:* Tuesday, December 6, 2022 12:34 PM > *To:* Sahir Vellani <sahir....@microsoft.com>; Mustaq Ahmed < > mus...@chromium.org>; Robert Flack <fla...@chromium.org> > *Cc:* blin...@chromium.org; Ben Mathwig <benjamin...@microsoft.com> > *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Prototype: > PointerEvent.deviceId for Mult-Pen Inking > > > > You don't often get email from rby...@chromium.org. Learn why this is > important <https://aka.ms/LearnAboutSenderIdentification> > > Cool, looks like a nice little addition to me. +Mustaq Ahmed and +Robert > Flack from the Chrome interactions team who are likely code reviewers. > > > > The only real potential debate I see is around the details of the privacy > protections. If I understand correctly "per document instance" means that > the IDs will even be different across iframes in the same tab, and also > when a page is reloaded. Is that right? If so, I can't see how it would be > an issue. > > > > On Mon, Dec 5, 2022 at 12:49 PM 'Sahir Vellani' via blink-dev < > blin...@chromium.org> wrote: > > Contact emails > > bema...@microsoft.com, sahir....@microsoft.com > > Explainer > > > https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2FPointerEventDeviceId%2Fexplainer.md&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579474144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EsOgFOzsHPc%2Fj%2F%2BTJ9hflwtRxorbyd7hF41%2BLjI0ZBU%3D&reserved=0> > > Specification > > > https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2FPointerEventDeviceId%2Fexplainer.md&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579474144%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EsOgFOzsHPc%2Fj%2F%2BTJ9hflwtRxorbyd7hF41%2BLjI0ZBU%3D&reserved=0> > > > > FWIW with my former PointerEvents spec editor hat on, I pinged this issue > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fpointerevents%2Fissues%2F353&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=osa71PvGzL%2BDGjx39Axkb1caplRW7jqxnGzlzRNz57U%3D&reserved=0> > on the PointerEvents spec. We've had 'extensions' to the PointerEvents spec > in the past, so the PEWG may be amenable to something simple and pragmatic > that'll naturally make it into the next official PE spec rather than > starting with WICG. But with my Blink API owner hat on, either path is fine. > > > > Summary > > As devices with advanced pen input capabilities are becoming increasingly > prevalent, it is important that the web platform continues to evolve to > fully support these advanced features in order to unlock rich experiences > for both end users and developers. One such advancement is the ability for > a device's digitizer to recognize more than one pen device interacting with > it simultaneously. This feature is an extension to the PointerEvent > interface to include a new attribute, deviceId, that represents a > session-persistent, document isolated, unique identifier that a developer > can reliably use to identify individual pens interacting with the page. > > > > Blink component > > Blink>Input > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Flist%3Fq%3Dcomponent%3ABlink%253EInput&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EFrGRopXCM0LJfTkMGXloPUsfPM6kTU%2BXNGfDqTMiGw%3D&reserved=0> > > Motivation > > Currently, developers have no way to distinguish between two individual > pens on an ink-enabled digitizer. The existing PointerEvent.id attribute is > implemented in different ways and does not always persist for each ink > stroke or interaction with the screen. Developers can use this change to > have a secure and reliable way to identify individual pen (pointers) > interacting with the screen in order to set specific colors or pen shapes > for each device interacting with the digitizer. > > > > Initial public proposal > > > https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2FPointerEventDeviceId%2Fexplainer.md&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ICpPXSjDr6YIR8kUwmRvDc5PvqGmMBJ9WxGi64ZagHU%3D&reserved=0> > > TAG review > > > > TAG review status > > Pending > > Risks > > Fingerprinting risks, which will be mitigated by randomizing the ID each > renderer session. > > Interoperability and Compatibility > > > > *Gecko*: Request for Position: Extending the PointerEvent with Unique > DeviceId Attribute · Issue #715 · mozilla/standards-positions · GitHub > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fstandards-positions%2Fissues%2F715&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=q5R7V4mQDV01AEkBJiY%2BG2OKdAgomwlJy4thA%2FagGMI%3D&reserved=0> > > *WebKit*: Request for Position: Extending the PointerEvent with Unique > DeviceId Attribute · Issue #102 · WebKit/standards-positions · GitHub > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWebKit%2Fstandards-positions%2Fissues%2F102&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=50aSzcEF%2FTZiR2ai679NTDXYbD749Ranuj4mtXZqEBw%3D&reserved=0> > > *Web developers*: No signals > > *Other signals*: > > WebView application risks > > *Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications?* > > None > > Debuggability > > deviceId will be available via DevTools for front-end debugging. > > Is this feature fully tested by web-platform-tests > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%2F%2B%2Fmain%2Fdocs%2Ftesting%2Fweb_platform_tests.md&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WU1d6ffoGTwByu5JTQRHftrquyyf78MKEOF3TrEpfcc%3D&reserved=0> > ? > > No > > > > We've got automation plumbing for the rest of PointerEvents I believe. Any > reason not to add plumbing through WebDriver for this too and an automated > WPT test? I suppose the value is pretty low, but IMHO would be nice if it's > not too much more expensive than the alternative chromium-only tests. > > > > Flag name > > PointerEventDeviceId > > Requires code in //chrome? > > False > > Estimated milestones > > No milestones specified > > > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/5114132234240000 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromestatus.com%2Ffeature%2F5114132234240000&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LPPFhNDrpyutVflW4%2FZ6SAYCTi4pBbaCSpJY4RzaoCQ%3D&reserved=0> > > This intent message was generated by Chrome Platform Status > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromestatus.com%2F&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SGZ6z4qV1VTSTgPJrwJf86sEkxaJe329cJgqVwSNJWA%3D&reserved=0> > . > > > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SA0PR00MB1033E5DE0BDE42239E647E9AFB189%40SA0PR00MB1033.namprd00.prod.outlook.com > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fchromium.org%2Fd%2Fmsgid%2Fblink-dev%2FSA0PR00MB1033E5DE0BDE42239E647E9AFB189%2540SA0PR00MB1033.namprd00.prod.outlook.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=y4lyVXVYRJyoigfHIJXAjWYcXPEk1IT50O3inXUyBTw%3D&reserved=0> > . > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/870380fe-ab9a-4925-8db1-261efa233295n%40chromium.org > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fchromium.org%2Fd%2Fmsgid%2Fblink-dev%2F870380fe-ab9a-4925-8db1-261efa233295n%2540chromium.org%3Futm_medium%3Demail%26utm_source%3Dfooter&data=05%7C01%7Csahir.vellani%40microsoft.com%7Cc1faa947d4fa434dd68708dade16fbba%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C638066487579630345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QmNuOrk%2BuTR5eryN3Wfpb6zkLQD4f2iTXsW%2FEIrzxJ8%3D&reserved=0> > . > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-0%2B98GOyXsx9kxrc-cTtL68hd4a%3DK3UsTtC1hSkjKALg%40mail.gmail.com.
