Announcement

Collapse
No announcement yet.

Chrome 86 Beta Enables Native File-System API By Default, WebCodecs Added

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Chrome 86 Beta Enables Native File-System API By Default, WebCodecs Added

    Phoronix: Chrome 86 Beta Enables Native File-System API By Default, WebCodecs Added

    Building off the recent release of Chrome 85, Google has now released the beta of Chrome 86 with a number of goodies introduced and promotions for some existing functionality...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    You can now easily enable vaapi / video acceleration in chrome 86 from chrome://flags

    Comment


    • #3
      "powerful web apps that interact with files on the user's local device"
      And so now you're really better off putting that into container or VM, because guess what is going to happen next...

      Comment


      • #4
        Originally posted by SystemCrasher View Post
        And so now you're really better off putting that into container or VM, because guess what is going to happen next...
        The API still requires the user to explicitly pick what they want to grant using a privileged file chooser dialog. What this API does is:
        1. Allow the application to keep a persistent handle for the length of the session (ie. until you close all tabs on that origin) so it doesn't have to redisplay the file chooser every time you click a button like Save. (With existing APIs, web apps are limited to "Save As..." without "Save")
        2. Allow the application the option to display a directory picker instead of a file picker.
        As implemented by Chrome, it also displays an indicator that a tab has file permissions granted, similar to how browsers display an indicator if a tab has been granted access to the camera and/or microphone. (In this case, it displays an icon in the omnibox which you can click to get a list of granted files/directories and revoke them at any time.)

        ...so it's basically the web version of how the XDG File Chooser portal for Flatpaks and Snaps works. (It requests a privileged chooser dialog and, if you click OK, what you chose gets mounted into the application sandbox for the duration of the session.)
        Last edited by ssokolow; 03 September 2020, 08:41 PM.

        Comment


        • #5
          There is funny engineering principle: if something could go wrong, it would. So I can imagine this feature would give birth to all kinds of mischief.

          As for persistence and sessions, aren't there e.g. background workers that could run detached from "tabs" or something, even quite some time after user thinks they "closed it"?

          As for directory pickers and so on I can imagine apps would readily scan dirs - and send content to their servers if they can access this kind of information.

          Then most of users aren't system level geniuses and would just click. Unhealthy things would happen.

          Comment


          • #6
            Goodbye Electron, and good riddance. Local file system support is what most Electron developers stood by as their sole argument for using Electron, instead of making their web app a PWA.

            Comment


            • #7
              Originally posted by SystemCrasher View Post
              And so now you're really better off putting that into container or VM, because guess what is going to happen next...
              I thought the same thing initially, and clicked on the spec, but it looks like it'll require pretty explicit user permissions, similarly to the microphone/camera APIs. I honestly clicked it looking for a reason to hate it, but I've definitely wanted to interact with the filesystem directly rather than having to redirect out and back in when building SPAs before.

              Comment


              • #8
                Originally posted by mmstick View Post
                Goodbye Electron, and good riddance. Local file system support is what most Electron developers stood by as their sole argument for using Electron, instead of making their web app a PWA.
                I will buy a big cake the day electron dies, and it will be a massive party. Its like the Margaret Thatcher of computers.

                Comment


                • #9
                  Originally posted by FireBurn View Post
                  You can now easily enable vaapi / video acceleration in chrome 86 from chrome://flags
                  So they finally accepted the community patches hum? We are living a age of Linux desktop miracles. First Firefox, now Chrome allow hardware accelerated video.

                  Tomorrow I'm hopping to finally have my beloved Flash support back in place. How can we surf the web without it? So many abandoned websites broken, so sad. I want to see them back to their former glory.

                  /s

                  Comment


                  • #10
                    Originally posted by SystemCrasher View Post
                    There is funny engineering principle: if something could go wrong, it would. So I can imagine this feature would give birth to all kinds of mischief.

                    As for persistence and sessions, aren't there e.g. background workers that could run detached from "tabs" or something, even quite some time after user thinks they "closed it"?

                    As for directory pickers and so on I can imagine apps would readily scan dirs - and send content to their servers if they can access this kind of information.

                    Then most of users aren't system level geniuses and would just click. Unhealthy things would happen.
                    Just prompt the users. "You need to click C:\Documents and Settings"

                    Comment

                    Working...
                    X