LGTM1 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/CAL5BFfVJcgag5VphS7oVhddgjdUX4c-2WM4pqC4_yWDLt%2B0g_g%40mail.gmail.com.
