On Thu, Nov 24, 2022 at 11:55 AM Yoav Weiss <[email protected]> wrote:
> LGTM1 > That's actually an LGTM2 On Thu, Nov 24, 2022 at 4:53 PM Rick Byers <[email protected]> wrote: > >> >> On Thu, Nov 24, 2022 at 4:03 AM François Beaufort <[email protected]> >> wrote: >> >>> >>> On Wed, Nov 23, 2022 at 6:21 PM Yoav Weiss <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Wed, Nov 23, 2022 at 6:14 PM Rick Byers <[email protected]> wrote: >>>> >>>>> Seems like a tiny addition to a well supported pattern. LGTM1 from my >>>>> perspective. >>>>> >>>>> Other comments inline >>>>> >>>>> On Wed, Nov 23, 2022 at 12:02 PM Yoav Weiss <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Nov 23, 2022 at 5:15 PM 'François Beaufort' via blink-dev < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Contact emails >>>>>>> >>>>>>> [email protected], [email protected] >>>>>>> >>>>>>> Explainer >>>>>>> >>>>>>> https://github.com/w3c/mediasession/issues/274 >>>>>>> >>>>>>> Specification >>>>>>> >>>>>>> >>>>>>> https://w3c.github.io/mediasession/#dom-mediasessionaction-previousslide >>>>>>> >>>>>>> https://w3c.github.io/mediasession/#dom-mediasessionaction-nextslide >>>>>>> >>>>>>> API spec >>>>>>> >>>>>>> Yes >>>>>>> >>>>>>> Summary >>>>>>> >>>>>>> Adds "previousslide" and "nextslide" actions to the existing Media >>>>>>> Session API. >>>>>>> >>>>>>> Blink component >>>>>>> >>>>>>> Blink>Media>Session >>>>>>> >>>>>>> Motivation >>>>>>> >>>>>>> This will enable developers of video conferencing websites to handle >>>>>>> these actions from browser UI. For example, if the user puts their >>>>>>> slides >>>>>>> presentation into a picture-in-picture window, the browser could display >>>>>>> buttons for navigating through slides. When the user clicks those, the >>>>>>> website handles them through the Media Session API. >>>>>>> >>>>>> >>>>>> Neat! :) >>>>>> >>>>>> >>>>>>> >>>>>>> TAG review >>>>>>> >>>>>>> This small addition to the Media Session API doesn’t seem to qualify >>>>>>> for a TAG review. >>>>>>> >>>>>>> Note that one for video conferencing actions was approved previously >>>>>>> at https://github.com/w3ctag/design-reviews/issues/608 >>>>>>> >>>>>> >>>>> Thanks, that's good to see. The explainer >>>>> <https://gist.github.com/steimelchrome/d52f0fb9a0a13c63a3cf2d4134b71682> >>>>> linked there was also helpful to me to quickly understand how this is >>>>> used. >>>>> >>>>> TAG review status >>>>>>> >>>>>>> N/A >>>>>>> >>>>>>> Debuggability >>>>>>> >>>>>>> No DevTools changes are required, treated like any other >>>>>>> attribute/enum. >>>>>>> >>>>>>> Risks >>>>>>> >>>>>>> >>>>>>> Interoperability and Compatibility >>>>>>> It’s low risk as it's a small addition to an existing API that both >>>>>>> Gecko and WebKit approve of. >>>>>>> >>>>>>> >>>>>>> Signals from other implementations (Gecko, WebKit): >>>>>>> >>>>>>> Gecko: Positive ( >>>>>>> https://github.com/w3c/mediasession/pull/284#pullrequestreview-1106405304 >>>>>>> ) >>>>>>> >>>>>>> WebKit: Positive ( >>>>>>> https://github.com/w3c/mediasession/pull/284#issuecomment-1217526791 >>>>>>> ) >>>>>>> >>>>>> >>>>>> Can you file for official positions? https://bit.ly/blink-signals >>>>>> >>>>> >>>>> Personally I'd be also fine calling this "no signals" - it's a very >>>>> tiny addition and Gecko and WebKit already support the general pattern. >>>>> >>>>> In general I feel like we should have some pattern for making small >>>>> tweaks to exposed APIs that doesn't pollute these standards position >>>>> repositories with noise. Yoav, WDYT? >>>>> >>>> >>>> I'm fine with calling this "no official signal" while pointing to the >>>> PR comments. >>>> I was mostly trying to avoid them feeling we're misrepresenting their >>>> opinions >>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/bYZK81WxYBo/m/2WGAimSPBAAJ> >>>> . >>>> >>> >>> As suggested, I've updated >>> https://chromestatus.com/feature/5090980649238528 with "No signal" for >>> both Safari and Firefox. >>> >> >> Great, thanks. For others who are curious, Mozilla confirmed >> <https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/q5C44gYgqyA> >> they don't expect position requests for trivial things like this. >> >> Yoav, any other concerns? >> > > No further concerns :) > > >> >> Web / Framework developers: Positive - The existence of the popular >>>>>>> (100K+ users) Remote for Slides extension ( >>>>>>> https://chrome.google.com/webstore/detail/remote-for-slides/pojijacppbhikhkmegdoechbfiiibppi) >>>>>>> proves that there is strong user demand for a (remote) slide control >>>>>>> feature, up to the point that they would install an extension just for >>>>>>> that. >>>>>>> >>>>>> >>>>> Nice signal! >>>>> >>>>> >>>>>> Ergonomics: >>>>>>> >>>>>>> N/A >>>>>>> >>>>>>> Activation: >>>>>>> >>>>>>> Web developers will be able to simply set/unset a media session >>>>>>> action handler for “Previous Slide” and “Next Slide” to control the >>>>>>> visibility of the button in the Picture-in-Picture window. When the >>>>>>> action >>>>>>> name is not supported, it raises a TypeError which can be caught to >>>>>>> detect >>>>>>> feature support. >>>>>>> >>>>>>> Is this feature fully tested by web-platform-tests? >>>>>>> >>>>>>> https://wpt.fyi/results/mediasession/setactionhandler.html >>>>>>> >>>>>> >>>>> Will someone be adding the two new actions to this test? You'll >>>>> probably want the new ones in a separate test case. >>>>> >>>> >>> We'll be adding two tests indeed. See WIP Chromium CL changes at >>> https://chromium-review.googlesource.com/c/chromium/src/+/3835037/19/third_party/blink/web_tests/external/wpt/mediasession/setactionhandler.html >>> >>> >> >> Figured, thanks. >> >> >>> >>>>> The test is pretty trivial - just makes sure actions can be added, >>>>> without verifying that callbacks get invoked. But IMHO I wouldn't >>>>> personally see building an automation pipeline for testing the callbacks >>>>> as >>>>> high priority. >>>>> >>>>> Tracking bug >>>>>>> >>>>>>> https://crbug.com/1363548 >>>>>>> >>>>>>> Estimated milestones >>>>>>> >>>>>>> DevTrial on desktop 110 >>>>>>> >>>>>>> DevTrial on Android 110 >>>>>>> >>>>>>> Link to entry on the Chrome Platform Status >>>>>>> >>>>>>> https://chromestatus.com/feature/5090980649238528 >>>>>>> >>>>>>> -- >>>>>>> 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 [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5%2Bn-3MqwWueapG7K_3GoRSCJ4L1dRq6zmj%3DW2cQ2XT%2BYA%40mail.gmail.com >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5%2Bn-3MqwWueapG7K_3GoRSCJ4L1dRq6zmj%3DW2cQ2XT%2BYA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWeKA6%2BYj9j0dmLfAUJMSV23PW0ZKL7ZR%2BZGHSRrJrb%2BA%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWeKA6%2BYj9j0dmLfAUJMSV23PW0ZKL7ZR%2BZGHSRrJrb%2BA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9WjQDZDnEFxydRkH3-NcLpuLw-rnmtxwrMcUPtrtbGmA%40mail.gmail.com.
