Consider making the API async

explainers-by-googlers / partitioned-popins

Explainer: Partitioned Popins

https://explainers-by-googlers.github.io/partitioned-popins/

Creative Commons Attribution 4.0 International

4 stars 1 forks source link

Consider making the API async #11

Open uazo opened 2 months ago

uazo commented 2 months ago

The proposal uses window.open which is synchronous. This would not easily allow the development of browsers that require authorisation from the user before opening the popin. Would it be possible to rethink the api call?

arichiv commented 2 months ago

Could you elaborate on the flow you're describing? I'm not against using something besides window.open, it just seemed like the best current match.

uazo commented 2 months ago

What I propose is to evaluate a call like

await window.openPopip(...);

therefore return a promise.

the advantages I believe are:

using an async API is more modern, w3c specifies it best
you can eliminate support for the detection you are proposing
potentially not introduce regressions in browsers that do not support popins
is more easily exploited (development-side) for possible asynchronous user request management

johannhof commented 1 month ago

I think conceptually I like the idea of getting a Promise from the opened pop-in, returning a result from the user interaction that happened in the pop-in seems like a common pattern and making that more modern / ergonomic feels worthwhile.

With that said, maybe there are advantages to utilizing the existing API that aren't apparent at first glance. Probably worth investigating!

uazo commented 1 month ago

interesting to note that suggestions are of no use...

https://issues.chromium.org/issues/340606651

so what is this repo for?

arichiv commented 1 month ago

I disagree that suggestions are of no use, but not all suggestions will be taken and those taken may not be adopted on the timeline requested.

This project is still just being prototyped, and has not even entered the origin trial phase (let alone contemplating shipping). Feedback not addressed so far may be addressed in the future.

Also, the more feedback on the same point we get from multiple developers/vendors the more prioritized that piece of feedback is likely to be.