Hi,
I’ve used regular Filesystem storage in order to provide custom fonts for WebView component.
Fonts are stored in
Expo.FileSystem.documentDirectory
and the WebView has the source property
source={{html: codeInject(html), baseUrl: global.baseUrl}}
// where global.baseUrl = Expo.FileSystem.documentDirectory
After migrating to SDK 32 using baseUrl pointing to Expo.FileSystem.documentDirectory throws “unable to open URL”
What has changed regarding webview and filesystem ?
I’ve updated from 30 to 32. Just checked That issue also exist on 31. With sdk 30.0 I was able to point webview to load local assets saved with local filesystem expo class by setting the baseUrl param on webview. Now it seems impossible.
Sure here you go:
run it with sdk 30 you get two WebView components, run with 31+ you get only first.
I dont see warnings with snack but unhandled promise rejection on accessing this location is thrown from webview (or some part it depends on).
Sure,
https://snack.expo.io/@michalkrakow/webviewlocalstoragetest
You get two webview instances with sdk 30 and only first with 31 (and 32).
I dont see any warnings with snack but unhandled promise rejection is thrown somewhere regarding attempt to access the filestorage location.
Thanks for sharing that, I’m bringing this up internally and hopefully will have an answer for you soon 
the error log:
[Unhandled promise rejection: Error: Unable to open URL: file:///var/mobile/Containers/Data/Application/54924710-5DF9-4658-8F7C-50D8FA202FEE/Documents/ExponentExperienceData/@michalkrakow/wiadomoscipwc/]
- node_modules\react-native\Libraries\BatchedBridge\NativeModules.js:146:41 in createErrorFromErrorData
- node_modules\react-native\Libraries\BatchedBridge\NativeModules.js:95:55 in <unknown>
- node_modules\react-native\Libraries\BatchedBridge\MessageQueue.js:397:4 in __invokeCallback
- node_modules\react-native\Libraries\BatchedBridge\MessageQueue.js:127:28 in <unknown>
- node_modules\react-native\Libraries\BatchedBridge\MessageQueue.js:297:10 in __guard
- node_modules\react-native\Libraries\BatchedBridge\MessageQueue.js:126:17 in invokeCallbackAndReturnFlushedQueue
* [native code]:null in invokeCallbackAndReturnFlushedQueue
Got it,
from SDK 31 in order to access local storage you need to also iclude the path in:
originWhitelist={[]}
param of the WebView.
Something to put in docs i think 
Big thanks for taking interest!
Good catch! 
This change has been introduced in facebook/react-native#634e7e1, where React Native dropped support for file:// URLs inside WebViews. Related issue is facebook/react-native#19986.
Since the commit’s message suggests the change is intentional, I’m not sure working around this like you did will be the right solution in the long run. Maybe the proper solution would be to inject a custom override of localstorage that would call back to RN’s JS and set the values in AsyncStorage (using Communicating between JS and Native on react-native-community/react-native-webview)? 
Could you ellaborate on why react native team decided to do this?
To prevent people from linking file:// or other URLs inside RN WebViews
Cant think of any benefit this limitation introduce. What’s offered in exchange?
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.