Persist permission across sessions (somehow) or allow audio / video elements to load a FileSystemFileHandle

[carlosrafaelgn]

Hi, everyone!

I am currently working on a media player where the user has the ability to select several files at once to add them to a playlist.

After closing the media player and opening it again, the player restores the previous playlist. Unfortunately, (almost) to no use, since the user has to grant permission to all the files in the playlist again.

So, that leads me to the first idea: could there be a way to request the user for something like a "long term permission", like showOpenFilePicker({ permissionType: "long-term" })??? I would not mind having a warning displayed to the user to let them know they are granting the website access to those files for a long period.

I know this has implications, as most suggestions do. So, I have another idea that could be very helpful, at least in my case (sorry for being selfish here...)

Would it be possible to allow audio / video elements to use a FileSystemFileHandle as their src, without having to perform an algorithm like this (which involves calling requestPermission() and getFile()):

function loadMedia(fileHandle) {
    const options = {};
    if ((await fileHandle.queryPermission(options)) !== "granted") {
        if ((await fileHandle.requestPermission(options)) !== "granted") {
            return false;
        }
    }
    const file = await fileHandle.getFile();
    if (currentURL) {
        URL.revokeObjectURL(currentURL);
    }
    currentURL = URL.createObjectURL(file);
    audio.src = currentURL;
    return true;
}

Thanks for giving us a chance to suggest new features and new use cases! ☺️ 🙏

[Jaifroid]

It would be better to have a model whereby installation of the PWA provides persistence of permissions as in #238 , rather than adding yet another layer of permissions. If you add another layer of permission, my bet is that every developer will use that one, thus rendering the previous per-session permission more-or-less redundant.

[youk]

PWAs are dead. Just as multiple Google attempts to crawl up user's ass.

[Jaifroid]

PWAs are dead.

PWAs are not a Google technology. They are fully supported by Microsoft (even on old Edge), and Mozilla has support for the core technologies and for pinning a PWA as an app on an Android phone. Apple is not interested because PWAs would undermine its lucrative revenue stream from the App Store.

I don't understand the second half of your comment.

[youk]

I don't recall saying it is Google technology. I was saying it is one of the Google means of crawling up user's ass.

Apple is not interested because PWAs would undermine its lucrative revenue stream from the App Store.

No. Apple is not interested in PWAs because it relies on different business model. The business model exploited by Google is based on misleading people.

Mozilla has support for the core technologies and for pinning a PWA as an app on an Android phone.

I don't want to rain on your parade, but Mozilla is obviously done with PWAs – Firefox 85 is Here, But Mozilla is Killing PWA Features.

I don't understand the second half of your comment.

Too bad. Try taking off your Google-painted glasses.

[carlosrafaelgn]

It would be better to have a model whereby installation of the PWA provides persistence of permissions as in #238 , rather than adding yet another layer of permissions. If you add another layer of permission, my bet is that every developer will use that one, thus rendering the previous per-session permission more-or-less redundant.

@Jaifroid , indeed that would be a way out (I agree that it is much better than adding another layer of permission that developers could end up misusing).

Instead of writing the full reply here, I have just posted a comment/reply there: #238 (comment)

[slaymaker1907]

Why not just store the handle to a directory and then just use that along with the names of the specific files in a separate location? The main downside I can think of to this is that some directories aren't possible to use like the Downloads folder and that in some cases it can lead to broader privileges than are really required by the app. Both of those can be worked around in a lot of cases by storing the files in on app specific folder. This leads to duplication of data, but this isn't a huge deal in a lot of cases.

[carlosrafaelgn]

Hi, @slaymaker1907 !!!

Taking the new Android 11 permission architecture, for example, it would be somewhat complex (if possible, at all) to get a handle to a file's parent directory, even for a native app, because it is a limitation imposed by the OS, not by the browser.

For desktop Linux and Windows that would not be such a problem, but considering initiatives like Snap on Linux, I think it would not be wise to assume the situation would remain forever as it is now.

Of course, there is still Apple's iOS architecture, which is somewhat even more restrictive than Android 11's.

So, I believe that for this new API to thrive, it should take into consideration the most restrictive OS and start building upon that.

Check out my comment here, on this other issue: #238 (comment)

[ftreesmilo]

Is this a duplicate of #297 ?

[mkruisselbrink]

I think this is a duplicate of #297, yes.