[path_provider] Add support for web

[harryterkelsen]

We should add web support for path_provider

[MichelFR]

Since its not possible to access the filessystem on the web... how should this be done?

[TimWhiting]

I can imagine that this might be useful in some contexts on the web. Like which folder to open a file-download picker to. (For user content). For cached content, I'm not sure it makes sense on the web. But it is pretty annoying to get a flood of errors in the console on web when trying to use a package like google_fonts which uses this plugin.

[provokateurin]

I actually fixed it for the google_fonts package some days ago. Just update. But still a lot of packages use it like on mobile.

[ditman]

Some work related to federation is happening here:

#46307 (comment)

[simmi9]

I was trying to download a file on my Windows OS using path_provider. getDownloadsDirectory(), and faced issues related to platform, then found this existing issue link. Looks like I may not be able to do my task until this issue is resolved. Please add support for flutter web in this library.

[oliverbytes]

Patiently waiting

[johnareid54]

I am using Flutter (Channel beta, 1.21.0-9.1.pre, on Mac OS X 10.15.6 19G73, locale en) with path-provider 1.6.14, the following works on Android and IOS but fails when run on web, it does not return a path.

`import 'package:flutter/material.dart';
import 'package:hive/hive.dart';
import 'package:path_provider/path_provider.dart' as path_provider;

void main() async {
WidgetsFlutterBinding.ensureInitialized();
final appDocumentDir = await path_provider.getApplicationDocumentsDirectory();
Hive.init(appDocumentDir.path);
print(appDocumentDir.path);
runApp(MyApp());
}`

[ditman]

@johnareid54 path_provider is not supported at all in web. Also, there's no standard concept "filesystem" or "path" on web browsers, so we'll first need to figure that out before we can implement a path_provider plugin.

[johnareid54]

@ditman path_provider is not supported at all in web.
Yes after a few hours reading last night, I am beginning to understand the problem, but would it not be better to return null rather than not returning anything? I was looking to use a local database such as hive or sembast (which produces a different pub package for web), but both have workarounds for the web, but it means having to have one version for the web and another for mobile, which is far from ideal and goes against the overall concept of flutter.

[ditman]

would it not be better to return null rather than not returning anything?

@johnareid54 The default behavior for unimplemented plugins is to throw an UnimplementedError (which should be catchable from the App).

How is return null more helpful than something that you can try/catch? (Honest question, the plugin is already federated, so implementing a "return null" version would be quite fast to do)

[Katekko]

@johnareid54 path_provider is not supported at all in web. Also, there's no standard concept "filesystem" or "path" on web browsers, so we'll first need to figure that out before we can implement a path_provider plugin.

I think the better way to do something is open a default modal like when you are downloading something, will popop up a modal for you save the download in any place. We can use the same concept. Instead pick the path it self just will open some modal for us, for picking ours self

[jimmyhappy19920308]

I find web File System Access API belowd:
https://web.dev/file-system-access/
https://css-tricks.com/getting-started-with-the-file-system-access-api/

Not sure can help.

[ditman]

@yingming25 I've been following that API for a while, but as of now, it's not very well supported:

This may be another way to go: https://developer.mozilla.org/en-US/docs/Web/API/FileSystem

(But again, the above needs to be supported by dart or a plugin that collaborates with the path_provider, otherwise it won't make sense).

[mateisilviu]

I have a solution for Firebase storage, my issue was with PDF file, with this snippet you could download or preview PDF in browser.
Flutter Web download pdf as files from Firebase storage

[ditman]

It seems that both Chrome and Webkit are implementing the "Origin Private File System":

• Origin Private File System
• 4. Accessing the Origin Private File System

The API above seems to provide files + directories that are persisted in some form of "private storage" that the browser keeps hidden, like the sandboxed storages of mobile apps.

It is unclear to me what's the quota, or what happens if a user "clears their local storage", if users are going to be able to "pick" a file from the private storage (or you'll need to write your own filepicker for this), or how to make this work with XFile (maybe we need a major version bump to that package), but it looks promising!

(Firefox seems to be working on it too.)

[loic-hamdi]

@yingming25 I've been following that API for a while, but as of now, it's not very well supported:

This may be another way to go: https://developer.mozilla.org/en-US/docs/Web/API/FileSystem

(But again, the above needs to be supported by dart or a plugin that collaborates with the path_provider, otherwise it won't make sense).

It seems that from the link you shared, the FileSystem API implementation made excellent progress.

[ditman]

The most promising API at the moment is OPFS:

https://caniuse.com/native-filesystem-api

[ubershmekel]

I was reading a file in my flutter web project and got this error:

Error: Unsupported operation: _Namespace

I searched the web and found an answer that the browser can't read files. The solution has an if statement that checks if we're on the web or not. But I assumed there was a multi-platform fluttery way of doing it.

Then I found https://docs.flutter.dev/cookbook/persistence/reading-writing-files which pointed me to this issue:

Note: This recipe doesn’t work with web apps at this time. To follow the discussion on this issue, check out flutter/flutter issue #45296.

But all I really wanted was this line:

return await rootBundle.loadString('assets/my_text.txt');

Which I found in this answer.

I could open another issue complaining that the original error message is cryptic. But perhaps adding the information in this issue is enough?

[stuartmorgan]

@ubershmekel It looks like that recipe points to this issue because the recipe uses path_provider. The specific error you are referencing doesn't look like it's coming from path_provider though.

[gokhanmeteerturk]

Basic OPFS features are now supported by all major browsers. Isn't it enough to add support for at least the getApplicationDocumentsDirectory?

[ditman]

There's a good explainer here:

• https://web.dev/articles/origin-private-file-system

We may be able to improve some features of cross_file (like Save As...) using the API.

Note that the OPFS is private and invisible to the user, so anything that needs to be downloaded to the public user FS needs to be "saved as".