My 2 cents - rendering a document PiP would be great, but it wouldn't help our use case unless we also have interactivity - the reason we want a document is precisely *because* we want the user to be able to interact with the PiP. Rendering a document while keeping the video controls would be an acceptable fallback, but wouldn't really add too much value for our use case.
On Monday, May 6, 2024 at 5:05:28 PM UTC-4 ari picker wrote: > +1 for feature parity, but honestly, what I need right now is > Android no-video PiP content. > > On Thursday, May 2, 2024 at 1:32:16 PM UTC-5 Maratona app wrote: > >> Hi Tommy, thank you for replying. >> >> My first instinct is not really about what to do on Android, but *feature >> parity* with Desktop, for example: >> https://dlitsman.github.io/document-pip/ since it's already possible to >> make interactive PiP, it seems odd to not have the same experience for >> mobile, I know the implementations for Android may be a restriction for >> this, so only sharing my thoughts as an *user*. Other APIs like Push >> Notifcation, Web Share and Badging all seem to have feature parity, even if >> the UI is different for each platform, they are supported somehow. >> >> It feels unmotivated to adopt a new API that will only work for a >> specific platform, if there is a security reason behind this, it would be >> nice to prompt the user to allow the interaction or not, similar to >> allowing/denying Push Notifcations. At least I really enjoy this new API as >> a *temporary widget* for mobile devices, since it's not possible to >> build native widgets through PWA. I don't wanna be mean, only sharing >> initial thoughts and open to understand the real blockers. >> >> >> >> On Thu, May 2, 2024 at 3:05 PM Tommy Steimel <ste...@google.com> wrote: >> >>> Thanks for the interest in Document PiP on Android! >>> >>> Currently, we're not sure that it's feasible to make the pip window >>> interactive on Android (e.g. allowing HTML buttons to be clicked). Would an >>> API that only allows non-interactive pip (so you'd create an HTML document >>> that we'd show but would not receive user inputs) be useful in your >>> opinion? Or would it only be a useful API if the user could actually >>> interact with it? >>> >>> Thanks, >>> Tommy >>> >>> On Wed, May 1, 2024 at 6:11 PM Maratona app <man...@maratona.app> wrote: >>> >>>> +1 for PiP on Android, it works really well for features like Pomodoro >>>> Timer and To-do tasks and since PWA is growing... it seems a great feature >>>> to support. (Currently using PWA -> TWA) >>>> >>>> I know there is an workaround that is to build the feature using a >>>> <canvas>, capture stream and pass to video for original PiP support.... >>>> but >>>> it makes really hard to map all interactions. >>>> >>>> Anyway, awesome work ! >>>> >>>> On Wednesday, May 1, 2024 at 4:59:37 PM UTC-3 Sahil Talwar wrote: >>>> >>>>> +1 - would love PiP on Android as well. >>>>> >>>>> On Monday, April 29, 2024 at 8:43:26 AM UTC-4 ari picker wrote: >>>>> >>>>>> Thank you for all your work on PiP, it's awesome! >>>>>> I am very interested in PiP on Android. Is any progress being made, >>>>>> and is there an ETA for PiP landing on Android? >>>>>> >>>>>> On Tuesday, June 13, 2023 at 12:25:11 PM UTC-5 Tommy Steimel wrote: >>>>>> >>>>>>> In the future, we may be able to do something on Android that >>>>>>> doesn't support input without any change to Android APIs. If we wanted >>>>>>> input in the PiP window, it would require changes to Android itself. >>>>>>> That >>>>>>> said, we haven't seen any interest from web developers for an inputless >>>>>>> document PiP on Android, and there isn't really anything you can do >>>>>>> with an >>>>>>> inputless document PiP that you can't do with a canvas-back video PiP, >>>>>>> so >>>>>>> we haven't pursued anything on Android. >>>>>>> >>>>>>> On Tue, Jun 13, 2023 at 7:06 AM Philip Jägenstedt < >>>>>>> foo...@chromium.org> wrote: >>>>>>> >>>>>>>> Thanks Domenic for mentoring and vouching :) I took a very cursory >>>>>>>> look at the API shape and sent a small fix >>>>>>>> <https://github.com/WICG/document-picture-in-picture/pull/81>, >>>>>>>> thanks for reviewing that. >>>>>>>> >>>>>>>> The concerns on >>>>>>>> https://github.com/WebKit/standards-positions/issues/41 are device >>>>>>>> independence and portability. For the Android support, can you say >>>>>>>> anything about future expectations? Is this feature simply not >>>>>>>> important on >>>>>>>> mobile and it might be a desktop-only API for the foreseeable future, >>>>>>>> or >>>>>>>> would Android support make sense for some use cases? If so, does it >>>>>>>> seem >>>>>>>> tractable given the requisite changes to Android APIs? >>>>>>>> >>>>>>>> On Tue, Jun 13, 2023 at 4:16 AM Domenic Denicola < >>>>>>>> dom...@chromium.org> wrote: >>>>>>>> >>>>>>>>> I was the spec mentor for Tommy's work on this feature, and am >>>>>>>>> chiming in to provide the requested spec maturity summary >>>>>>>>> <https://www.chromium.org/blink/launching-features/#:~:text=If%20your%20specification%20isn%27t%20a%20modification%20of%20an%20existing%20specification%2C%20include%20a%20one%2Dline%20spec%20maturity%20summary%20from%20someone%20outside%20your%20team%20(like%20your%20spec%20mentor)%20who%20has%20done%20a%20review.> >>>>>>>>> . >>>>>>>>> >>>>>>>>> I'm very happy with the spec work for this feature. Tommy worked >>>>>>>>> hard to incorporate all my feedback about how to ensure everything >>>>>>>>> was >>>>>>>>> rigorously defined, and integrated well with existing concepts like >>>>>>>>> opening >>>>>>>>> new windows (navigables). The monkey patches are small, focused, and >>>>>>>>> easy >>>>>>>>> to understand. >>>>>>>>> >>>>>>>>> There is some TAG feedback that seems to wish this was part of >>>>>>>>> window.open() or some other more-general API, but I think that advice >>>>>>>>> is >>>>>>>>> not correct, and the current API design is good, due to the >>>>>>>>> singleton-per-top-level-traversable nature of a document PiP window. >>>>>>>>> In my >>>>>>>>> opinion this makes the window.documentPictureInPicture entrypoint, >>>>>>>>> with its >>>>>>>>> requestWindow(), window, and onenter properties, a good API for the >>>>>>>>> use >>>>>>>>> case. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jun 13, 2023 at 1:51 AM 'Tommy Steimel' via blink-dev < >>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>> >>>>>>>>>> Contact emailsste...@chromium.org, libe...@chromium.org, >>>>>>>>>> y...@chromium.org >>>>>>>>>> >>>>>>>>>> Explainer >>>>>>>>>> https://github.com/WICG/document-picture-in-picture/blob/main/README.md >>>>>>>>>> >>>>>>>>>> Specificationhttps://wicg.github.io/document-picture-in-picture >>>>>>>>>> >>>>>>>>>> Summary >>>>>>>>>> >>>>>>>>>> Document PiP adds a new API to open an always-on-top window that >>>>>>>>>> can be populated with arbitrary HTMLElements. This is an expansion >>>>>>>>>> upon the >>>>>>>>>> existing HTMLVideoElement API that only allows for an >>>>>>>>>> HTMLVideoElement to >>>>>>>>>> be put into a PiP window. This allows web developers to provide a >>>>>>>>>> better >>>>>>>>>> PiP experience to users. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Blink componentBlink>Media>PictureInPicture >>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EMedia%3EPictureInPicture> >>>>>>>>>> >>>>>>>>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/798 >>>>>>>>>> >>>>>>>>>> TAG review statusIssues open >>>>>>>>>> >>>>>>>>>> Risks >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Interoperability and Compatibility >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *Gecko*: No signal ( >>>>>>>>>> https://github.com/mozilla/standards-positions/issues/670) >>>>>>>>>> >>>>>>>>>> *WebKit*: No signal ( >>>>>>>>>> https://github.com/WebKit/standards-positions/issues/41) no >>>>>>>>>> official position, but have some concerns >>>>>>>>>> >>>>>>>>>> *Web developers*: Positive ( >>>>>>>>>> https://discourse.wicg.io/t/proposal-document-picture-in-picture/5736/2?u=steimel) >>>>>>>>>> >>>>>>>>>> In addition to the linked comment, we have some signals from >>>>>>>>>> partners that >>>>>>>>>> this would be valuable, and are checking to see if they are OK >>>>>>>>>> making that >>>>>>>>>> public >>>>>>>>>> >>>>>>>>>> *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? >>>>>>>>>> >>>>>>>>>> N/A since we are not enabling this API on Android >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Debuggability >>>>>>>>>> >>>>>>>>>> The new methods and properties proposed in this spec will show up >>>>>>>>>> in autocomplete functionality (e.g. >>>>>>>>>> window.documentPictureInPicture). The >>>>>>>>>> enter event will support event listener breakpoints in the >>>>>>>>>> "Picture-in-Picture" category. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?No >>>>>>>>>> >>>>>>>>>> At least initially, we're not supporting Android since the >>>>>>>>>> Android APIs don't easily support always-on-top windows with >>>>>>>>>> arbitrary >>>>>>>>>> interaction >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>> ?Yes >>>>>>>>>> >>>>>>>>>> Flag nameblink::features::kDocumentPictureInPictureAPI >>>>>>>>>> >>>>>>>>>> Requires code in //chrome?True >>>>>>>>>> >>>>>>>>>> Tracking bughttps://crbug.com/1315351 >>>>>>>>>> >>>>>>>>>> Launch bughttps://crbug.com/1269059 >>>>>>>>>> >>>>>>>>>> MeasurementWe have UseCounters for the documentPictureInPicture >>>>>>>>>> APIs >>>>>>>>>> >>>>>>>>>> Availability expectationFeature is available only in Chromium >>>>>>>>>> browsers for the foreseeable future >>>>>>>>>> >>>>>>>>>> Adoption expectationFeature is used by specific partner(s) to >>>>>>>>>> provide functionality within 12 months of launch in Chrome >>>>>>>>>> >>>>>>>>>> Adoption planFeature is already being used in the OT by partners >>>>>>>>>> who plan to continue using the feature in stable >>>>>>>>>> >>>>>>>>>> Non-OSS dependencies >>>>>>>>>> >>>>>>>>>> Does the feature depend on any code or APIs outside the Chromium >>>>>>>>>> open source repository and its open-source dependencies to function? >>>>>>>>>> N/A >>>>>>>>>> >>>>>>>>>> Estimated milestones >>>>>>>>>> Shipping on desktop 116 >>>>>>>>>> OriginTrial desktop last 115 >>>>>>>>>> OriginTrial desktop first 111 >>>>>>>>>> >>>>>>>>>> Anticipated spec changes >>>>>>>>>> >>>>>>>>>> Open questions about a feature may be a source of future web >>>>>>>>>> compat or interop issues. Please list open issues (e.g. links to >>>>>>>>>> known >>>>>>>>>> github issues in the project for the feature specification) whose >>>>>>>>>> resolution may introduce web compat/interop risk (e.g., changing to >>>>>>>>>> naming >>>>>>>>>> or structure of the API in a non-backward-compatible way). >>>>>>>>>> No future backwards-incompatible spec changes anticipated >>>>>>>>>> >>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>> https://chromestatus.com/feature/5755179560337408 >>>>>>>>>> >>>>>>>>>> Links to previous Intent discussionsIntent to prototype: >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGyVZ8L-SmBFbBMvvbm0x3TwZ66JQ1Fm7_zb3nSiBvYhXavAuA%40mail.gmail.com >>>>>>>>>> Intent >>>>>>>>>> to Experiment: >>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/Tz1gUh92dXs >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>> <https://chromestatus.com/>. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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/CAE-AwAr2EHEEbqD0X-7bt_4NGAxFhyRz_0wv2c6Bvi65iYw30Q%40mail.gmail.com >>>>>>>>>> >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE-AwAr2EHEEbqD0X-7bt_4NGAxFhyRz_0wv2c6Bvi65iYw30Q%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 blink-dev+...@chromium.org. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9xZXrXi9f8upH7EZdaF2mOgn%3DVz5ZnDR%2B3xdEaHiG8LQ%40mail.gmail.com >>>>>>>>> >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9xZXrXi9f8upH7EZdaF2mOgn%3DVz5ZnDR%2B3xdEaHiG8LQ%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a7e35ab2-f6c8-47bf-a169-dea7ce85341cn%40chromium.org.
