Hi all, the specification contains numerous (9) references to "user permission", yet there is no section about Permissions API and Permissions Policy integration, as well as Permissions Policy feature/declaration and default allow list. Is this intentional? Of course, this could be accidental since the API dates to circa 2016 when Permissions Policy was not a thing yet and Permissions API was very fresh.
Thanks On Tuesday, November 7, 2023 at 11:07:12 PM UTC+2 Muyao Xu wrote: > Hi all, > > The Remote Playback API is now targeting to ship to M121 on Win/Mac/Linux. > There's no change to the spec or the API. The Chrome Status entry has been > updated. > On Wednesday, November 30, 2016 at 9:39:53 AM UTC-8 Anton Vayvod wrote: > >> On Wed, Nov 30, 2016 at 11:33 AM Jochen Eisinger <joc...@chromium.org> >> wrote: >> >>> I was wondering why there's no security & privacy consideration section >>> (open issue https://github.com/w3c/remote-playback/issues/67)? >>> >> >> We don't expect to have more there than the Presentation API ( >> https://w3c.github.io/presentation-api/#security-and-privacy-considerations) >> since Remote Playback API doesn't have the receiver browser context or >> identifiers for reconnection to a device and exposes only one bit of >> information in a similar way about device availability. >> >> That said, the issue definitely slipped through and I'll look into >> updating the issue with the self-questionnaire responses and adding a draft >> section to the spec now. Thanks for noticing! >> >> >>> >>> On Mon, Nov 28, 2016 at 8:34 PM Anton Vayvod <ava...@chromium.org> >>> wrote: >>> >>>> ...and an after-holiday ping :) >>>> >>>> >>>> On Tue, Nov 22, 2016 at 12:23 PM Anton Vayvod <ava...@chromium.org> >>>> wrote: >>>> >>>>> A gentle ping. We'd need one more LGTM in order to ship. Thanks! >>>>> >>>>> >>>>> On Fri, Nov 18, 2016 at 8:00 AM Philip Jägenstedt <foo...@chromium.org> >>>>> wrote: >>>>> >>>>>> LGTM2 >>>>>> >>>>>> On Fri, Nov 18, 2016 at 2:03 AM Chris Harrelson <chri...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> LGTM1 >>>>>>> >>>>>>> On Thu, Nov 17, 2016 at 1:24 PM, Anton Vayvod <ava...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Nov 17, 2016 at 2:43 AM Philip Jägenstedt < >>>>>>>> foo...@chromium.org> wrote: >>>>>>>> >>>>>>>>> On Thu, Nov 17, 2016 at 12:59 AM Anton Vayvod <ava...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Comments inline: >>>>>>>>>> >>>>>>>>>> On Wed, Nov 16, 2016 at 1:40 AM Philip Jägenstedt < >>>>>>>>>> foo...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> There are some open issues >>>>>>>>>>> <https://github.com/w3c/remote-playback/issues>, most filed by >>>>>>>>>>> Chromium developers. Can you go through and resolve as many as >>>>>>>>>>> possible? >>>>>>>>>>> Issues which can't possibly change observable behavior are fine to >>>>>>>>>>> leave, >>>>>>>>>>> of course. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Mounir and I looked at the issues today. There's one minor issue >>>>>>>>>> that might result in an observable behavior change depending on what >>>>>>>>>> we >>>>>>>>>> agree at: https://github.com/w3c/remote-playback/issues/63. >>>>>>>>>> >>>>>>>>>> We're going to resolve it asap (I'll update this thread). >>>>>>>>>> >>>>>>>>> >>>>>>>>> Great! As long as you're confident that it'll be resolved in a >>>>>>>>> specific way, that other implementers will support it, and that >>>>>>>>> you'll >>>>>>>>> match that when shipping, this intent need not block, but if there's >>>>>>>>> no >>>>>>>>> hurry we can just wait for it to be resolved. >>>>>>>>> >>>>>>>> >>>>>>>> We checked how Safari is implementing >>>>>>>> <https://www.google.com/url?q=https%3A%2F%2Fbugs.webkit.org%2Fattachment.cgi%3Fid%3D292263%26action%3Dprettypatch&sa=D&sntz=1&usg=AFQjCNE4T6Lo6DjBj_CPQCdgwRSsIpbzwg> >>>>>>>> >>>>>>>> and resolved the issue with no change to the spec. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Browsing the IDL, I see that the implementation doesn't have the >>>>>>>>>>> "connecting" RemotePlaybackState enum value, is that the tip of an >>>>>>>>>>> iceberg >>>>>>>>>>> or would it be trivial to implement? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This was actually just a missing enum value in the idl file, the >>>>>>>>>> rest of the iceberg has been implemented before the Intent to Ship :) >>>>>>>>>> >>>>>>>>>> I've fixed the IDL, thanks for noticing (I wonder if Blink should >>>>>>>>>> verify enum values used?). >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yes, we should! The predictability program is working this quarter >>>>>>>>> on Blink IDL spec sync >>>>>>>>> <https://docs.google.com/document/d/1yKwaxvgm-8Ljuo4equXKaPey-HNhjyLnvp89cxscnhs/edit?usp=sharing>, >>>>>>>>> >>>>>>>>> and the tooling that +Mark Dittmer is building will eventually >>>>>>>>> allow us to see what differences there are for IDL files across >>>>>>>>> Blink, and >>>>>>>>> possible also have it as a presubmit check in the long term. >>>>>>>>> >>>>>>>> >>>>>>>> Great to hear! >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Is there a shared test suite for this, so that other implementers >>>>>>>>>>> can have some confidence that they're passing the same tests as our >>>>>>>>>>> implementation? I realize that automated tests for the actual >>>>>>>>>>> behavior >>>>>>>>>>> would require something that doesn't exist yet, but the >>>>>>>>>>> surface-level APIs >>>>>>>>>>> should be possible to test. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> We have some test-harness based tests >>>>>>>>>> <https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/media/remoteplayback/> >>>>>>>>>> >>>>>>>>>> for the various edge cases that don't require actual remote playback >>>>>>>>>> devices. The Second Screen WG is working on a test suite for the >>>>>>>>>> Presentation API atm, I expect their setup to work well for the >>>>>>>>>> Remote >>>>>>>>>> Playback API too. >>>>>>>>>> >>>>>>>>>> Do you have an example in mind of an additional tests we could >>>>>>>>>> write today though? >>>>>>>>>> >>>>>>>>> >>>>>>>>> It looks like only prompt-twice-throws.html uses internals, so >>>>>>>>> contributing the others to web-platform-tests would be great. To be >>>>>>>>> clear, >>>>>>>>> this is *not* yet a required part of any process, because >>>>>>>>> exporting tests isn't super easy, yet >>>>>>>>> <https://docs.google.com/document/d/1JgPTyIWmjlXyhyatiZ9A6fSbUQPjCyM26budEY90VDE/edit?usp=sharing> >>>>>>>>> . >>>>>>>>> >>>>>>>>> In addition to those tests, idlharness.js tests might be useful >>>>>>>>> just to cover the things that can be automatically tests based on the >>>>>>>>> spec's IDL alone, which cuts down on some very boring tests like >>>>>>>>> checking >>>>>>>>> that RemotePlayback does in fact inherit directly from EventTarget >>>>>>>>> and so >>>>>>>>> on. >>>>>>>>> >>>>>>>> >>>>>>>> Ok, we've filed a tracking issue >>>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=666465#c1> >>>>>>>> for this work and will target M57. >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>>> 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. >>>>>>>> >>>>>>> -- 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/322f8bf8-4b21-4a19-a817-2f685699a96en%40chromium.org.
