Can you share a repro? I tried a quick test and it was working for me.

Here's a repro for the issue: https://github.com/jacobpenny/webview-file-uri-repro

This code works fine on 11.21.2.

Thanks for the repro! This is interesting, it does look like you found a real regression. It seems the order in which properties are specified on a component matters! It was processing the source property (and thus trying to load the file) before the allowFileAccess property (code). Now I'm wondering if there are other issues related to this sort of thing... in general it seems like source should be the last thing to process... or, at least, second-to-last before nativeConfig (just to preserve the previous behavior which placed it there). Looks like it's still correct for other platforms too, things only got reordered on Android for some reason.

(I'm not certain, but I'm guessing my previous test might have worked by initializing source with some other value first and then updating it to the local filepath, by which point the allowFileAccess property would have been applied)

For what its worth, i've been battling with this issue for 2 days now, dropping back to older versions has not fixed the issue either, we did however upgrade to React Native 0.70.6 from 0.68 so a fair bit has changed.

Issue is as the ticket describes, we write out a HTML file to the file system before loading it into a webview on Android (we don't do this for iOS as we're able to pass in raw HTML)

We get this error on Android thrown back and a blank webview

WebView error:  {"canGoBack": false, "canGoForward": false, "code": -1, "description": "net::ERR_ACCESS_DENIED", "loading": false, "target": 7209, "title": "player.html", "url": "file:///data/user/0/com.ourapp.android/files/player.html"}

I've now tried rebuilding with a half dozen different webview versions going back to 11.17. Same issue.

Manifest includes

	<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
	<uses-permission android:name="android.permission.INTERNET" />
	<uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />
	<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />
	<uses-permission android:name="android.permission.VIBRATE" />
	<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
	<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

Webview options

			<WebView
				style={styles.webview}
				ref={viewRef}
				originWhitelist={["*"]}
				source={
					Platform.OS === "android"
						? {
								uri: `file://${localPlayerPath}`,
								baseUrl: "",
						  }
						: {
								html,
								baseUrl: "",
						  }
				}
				thirdPartyCookiesEnabled={true}
				allowsInlineMediaPlayback={true}
				sharedCookiesEnabled={true}
				allowsFullscreenVideo={true}
				scrollEnabled={false}
				scalesPageToFit={true}
				domStorageEnabled={true}
				androidLayerType="hardware"
				allowFileAccess={true}
				allowingReadAccessToURL={`file://${fs.DocumentDirectoryPath}`}
				allowUniversalAccessFromFileURLs={true}
				allowFileAccessFromFileURLs={true}
				javaScriptCanOpenWindowsAutomatically={true}

One thing I have noticed is that it will SOMETIMES work.. Like, maybe once every 20 errors.. So, it makes me think there is no actual permission error, there's a race condition somewhere.. We've tried delaying rendering etc, to make sure there wasn't a race condition after writing the file, but there's not, and the file write out just fine as we've inspected. There's something funky going on elsewhere

We've basically had to push forward releasing our IOS app and holding back the Android one due to this.. Everything works fine on Apple devices. We're too far down the hole to roll back the major React Native upgrade.

Any advice would be greatly appreciated

@cheynewallace If dropping back to older versions hasn't helped then I think you might be seeing a different issue. There was a very clear regression in 11.22.0 that broke this behavior.

The repro that @jacobpenny shared, which worked with previous versions of react-native-webview (and with the fix in #2766), uses RN 0.70, so I don't think there's a simple incompatibility there. Possibly comparing that with your project could provide a clue?

My other advice would be to attach Android Studio to try debugging it yourself. I can tell you that in the case of this original issue, I could see in the debugger that setSource was being invoked before setAllowFileAccess, meaning that the initial load of a local file failed but subsequent loads (after setAllowFileAccess had taken effect) succeeded.

Thanks for getting back to me @TheAlmightyBob, that all makes sense, I managed to get around it by doing a combination of rolling back to 11.21.2 and implementing the renderOnce method detailed here #656 (comment)

Its odd, because that render race condition issue appears quite old, however we've been using this library for a few years and never seen it until now (we were previously on 11.16). We upgraded a few other packages that had to go along with the 0.70 update as well, so maybe something there tripped it over, hard to say, we're just playing dependency jenga right now.

Anyway, our Android app looks more lively for now.. I'll keep an eye out for updates on that regression and the PR you submitted. Thanks again for your help and quick response 👍

@cheynewallace Thank you for linking that other issue, I was unaware of it. Very interesting... in my testing via @jacobpenny's repro, the order of properties in the JSX seemed to clearly determine the order in which they were applied in native code. But it seems you and others may have found that's not always the case?

If you could spare the time, I'd be curious if running @jacobpenny's repo with 11.21.2 still repros for you.... i.e. whether it's affected by environment/device/etc or project/usage details or something...

I think I'm going to keep #2766 focused on just reverting the simple regression, but it would be good to understand how props are applied...

@TheAlmightyBob Sure, I just pulled down the repro repo above, here's few things i found

• Yes I get the issue on that repo. Changing the ordering of the props also doesn't seem to change that.
• Dropping back to 11.21.2 still gives me the same permission error...I yarn'd, rebuilt the app. Not sure if I needed to clear all the build caches however.
• Implementing the render once fix I mentioned above however seems to resolve the issue, on all versions here. Iv bumped it back up to 11.25 and its not throwing.

Here's some example code for App.tsx that's working for me

import React, {useEffect, useState} from 'react';
import {SafeAreaView} from 'react-native';
import {Dirs, FileSystem} from 'react-native-file-access';
import {WebView} from 'react-native-webview';

const path = `${Dirs.DocumentDir}/test.html`;

const App = () => {
  const [ready, setReady] = useState(false);
  const [renderedOnce, setRenderedOnce] = useState(false);

  useEffect(() => {
    FileSystem.writeFile(
      path,
      '<html><h1>File Access is working if you are reading this.</h1></html>',
      'utf8',
    ).then(() => {
      setReady(true);
    });
  }, []);
  return (
    <SafeAreaView style={{flex: 1}}>
      {ready && (
        <WebView
          source={{uri: renderedOnce ? path : undefined}}
          allowFileAccess={true}
          onLoad={() => setRenderedOnce(true)}
        />
      )}
    </SafeAreaView>
  );
};

export default App;

Dropping back to 11.21.2 still gives me the same permission error

Curious. Thanks for the info.

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

Reopening because #2766 has not been merged yet

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

This comment helped me for a temporary solution.

#656 (comment)

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

'sup bot, please keep this open... unfortunately #2766 ran into some issues after the new architecture refactor...

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

Hi, Any luck on solution here?

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

When it is going to be fixed? Any idea?