feat(iOS): WKUserScripts (e.g. injectedJavaScript) can now update upon props change; and can be configured to inject into all frames.

[shirakaba]

Closes #824 (which was closed only due to inactivity)

Summary

Note: depends upon the minor PR #1118.

• In react-native-wkwebview, it is possible to update injectedJavascript and injectedJavaScriptBeforeContentLoad upon props change. But in react-native-webview, it is committed upon mount (as they are only initialised upon didMoveToWindow.
• Equally, react-native-wkwebview supports injecting JS into the main frame or all frames while react-native-webview injects only into the main frame. This means that the WebView has no influence over iframes, for example.

I implemented the solution by:

1. extracting the WKWebViewConfiguration initialisation routine from didMoveToWindow into a function called setUpWkWebViewConfig() (depends upon PR Extract wkWebViewConfig setup into setUpWkWebViewConfig function #1118), and;

2. extracting the WKUserConfig initialisation code from there into a function called resetupScripts().

resetupScripts() removes all user scripts (the HTML5 history shim; the cookie-sharing shim; the injectedJavaScript source; the injectedJavaScriptBeforeContentLoaded source; and the (postMessage) messaging source), then restores all which still apply, given the latest props.

resetupScripts() is called upon didMoveToWindow (the post-initialisation life-cycle method) and upon any change to the user scripts – be the change to the script itself or the frames to which they apply.

Test Plan

<WebView
  source={{ uri: "https://birchlabs.co.uk/linguabrowse/infopages/obsol/iframeTest.html" }}
  /* Must be populated in order for `messagingEnabled` to be `true` to activate the
   * JS injection user scripts, consistent with current behaviour. This is undesirable,
   * so I'll address it in a follow-up PR. */
  onMessage={(e) => {}}
  
  injectedJavaScriptBeforeContentLoadedForMainFrameOnly={true}
  /* We set this property in each frame */
  injectedJavaScriptBeforeContentLoaded={`window.self.colourToUse = "orange";`}
  
  injectedJavaScriptForMainFrameOnly={true}
  /* We read the colourToUse property in each frame to recolour each frame */
  injectedJavaScript={`window.self.document.body.style.backgroundColor = window.self.colourToUse;`}
/>

This should change each frame to have a background colour of orange upon loading. There are three frames here: yellow, pink, and – just out of curiosity – https://www.eBay.co.uk (which cannot be displayed because its X-Frame-Options is set to SAMEORIGIN). The eBay frame seems orange post-injection only because it has a transparent background; it blocks script injection by the user content controllers, and this is expected behaviour.

The page without any injected JS

The page after injected JS (main frame only)

The page after injected JS (all frames)

What's required for testing (prerequisites)?

Make assertions based on the background colour of a site with iframes successfully being changed, given the above props.

What are the steps to reproduce (after prerequisites)?

N/A (feature)

Compatibility

OS	Implemented
iOS	✅
Android	❌

Checklist

• I have tested this on a device
• I have tested this on a a simulator
• I added the documentation in README.md
• I mentioned this change in CHANGELOG.md
• I updated the typed files (TS and Flow)
• I added a sample use of the API in the example project (example/App.js)

[shirakaba]

I had to make a few extra bugfix commits and a few edits to the text and screenshots of the initial post, but I think I'm satisfied with my edits now so will stop changing it.

[safaiyeh]

@shirakaba Would this need to be implemented for Android as well?

[shirakaba]

@safaiyeh This would not technically need to be implemented for Android as I have only changed the React component props interface for the iOS NativeWebView component. I would of course eventually like to have this feature for Android, but I will be focusing on the iOS side of my app for the time being.

Android is rather far behind:

1. Although CommonNativeWebViewProps and WebViewSharedProps includes injectedJavaScriptBeforeContentLoaded, injectedJavaScriptBeforeContentLoaded is not implemented at all for Android to begin with.

2. injectedJavaScript has only a very basic implementation for Android. During the onPageFinished function, reactWebView.callInjectedJavaScript() is called. The current implementation only acts on the main frame and does not consider other frames. I don't know whether Android has an equivalent to the WKUserScript APIs for injecting into all frames at certain page load times. If Android WebView doesn't have a hook for frame load start and end, then things may get tricky to implement. Does anyone know whether it has these hooks?

However, on Android the injectedJavaScript does at least update on each prop change.

EDIT: It looks like there is an open PR for the implementation of injectedJavaScriptBeforeContentLoaded on Android: #1099

EDIT 2: I found that Android has no equivalent APIs available for injecting scripts into all frames, nor any lifecycle event fired by each frame upon start/end of page loading. So for Android, we can only practically support injecting into the main frame.

[safaiyeh]

@shirakaba Thanks for the updates. We usually like to wait for features to support both platforms. Since it is not possible on Android from your research, I'll review this PR sometime today.

[safaiyeh]

@shirakaba Partial review, could you resolve conflicts so the diff is easier to read?

[shirakaba]

@shirakaba Partial review, could you resolve conflicts so the diff is easier to read?

Done.

[safaiyeh]

@shirakaba Looks good to me, would you consider this a breaking change or just a feature?

I'm leaning towards breaking since it modifies how injectJavaScript is loaded and reacts to prop changes.

[shirakaba]

@safaiyeh A breaking change, because:

Breaking changes

1. Users may previously have accidentally been relying on the behaviour that any props updates to injectedJavaScript remained immutable after first being set.
2. This section: https://github.com/react-native-community/react-native-webview/pull/1119/files#diff-e2c6890fad2eec1786f059cac2d6d839L1012-L1019 injectedJavaScript no longer attaches a jsEvaluationValue property to the onLoadingFinish event.

Retaining the behaviour of collecting a JS evaluation value after injectedJavaScript

I would say that this could still be achieved by manually calling injectJavaScript() upon the onLoadedFinish event, but apparently that no longer returns an evaluation result for security reasons (reasons that admittedly I don't understand). It's quite possible that the jsEvaluationValue recorded upon that the evaluateJS() call (that this PR removes) was actually a security risk for the same reason and would therefore have been worth removing anyway. A good reason to remove it either way, though, is that it did not handle errors in JS evaluation gracefully (a warning log would appear in the console, but there would be no way to examine the error in code).

So instead, the best way to retain similar behaviour would be to collect the evaluation result of your JS by ensuring that your injectedJavaScript source string posts the result that it has evaluated:

<WebView
  source={{ uri: "https://birchlabs.co.uk/linguabrowse/infopages/obsol/iframeTest.html" }}
  /* Must be populated in order for `messagingEnabled` to be `true` to activate the
   * JS injection user scripts, consistent with current behaviour. */
  onMessage={(e: WebViewMessageEvent) => {
    const data = JSON.parse(e.nativeEvent.data);
    const { error, evaluation } = data;
    if(error === null){
      // The JS evaluation succeeded!
      console.log(`The expression evaluated as: ${evaluation}`);
    } else {
      // The JS evaluation failed
      console.log(`The expression evaluation failed, with message: ${error}`);
    }
  }}
  /* You could still inject it on all frames, but you'll see that we're just
   * evaluating 1+1, so we only really need it evaluated once :) */
  injectedJavaScriptForMainFrameOnly={true}
  injectedJavaScript={`
try {
  const expressionToEvaluate = 1 + 1;
  // Remember that the postMessage API only accepts a string as input.
  window.ReactNativeWebView.postMessage(
    JSON.stringify({ error: null, evaluation: expressionToEvaluate })
  );
} catch (e) {
  // Error objects don't stringify well, so we'll just report the error message.
  // I always add || e just in case we caught not an Error object, but an error string.
  window.ReactNativeWebView.postMessage(
    JSON.stringify({ error: e.message || e, expressionToEvaluation: null })
  );
}
`}
/>

Note that, unlike in the previous implementation, this posted message would appear in the onMessage handler rather than on the onLoadingFinish event, of course.

[safaiyeh]

@shirakaba Seems like a lot of friction for the end dev to get the old behavior to work. Is the removal necessary, is it possible to respond to the prop changes; however, and maintain attaching jsEvaluationValue to onLoadingFinish.

My concern is that the most common use is a static inject with no prop updates. I would not want to create friction with those developers.

[shirakaba]

Seems like a lot of friction for the end dev to get the old behavior to work.

Note the code comment on the injectJavaScript method:

Injects a javascript string into the referenced WebView. Deliberately does not return a response because using eval() to return a response breaks this method on pages with a Content Security Policy that disallows eval(). If you need that functionality, look into postMessage/onMessage.

injectJavaScript wraps the same evaluateJavaScript method used in the old behaviour – I think that the old behaviour (of returning a response upon evaluating some JS on onLoadFinish) is not secure fails on appropriately secured pages, but has remained up until now due to not being noticed.

The documentation comment recommends migrating to postMessage instead, so I think it would make sense to take this opportunity to deprecate that method.

Is the removal necessary, is it possible to respond to the prop changes

Although we can certainly make the old method respond to prop changes, the old method only supports injecting JS into the main frame; the only way to inject into all frames is to migrate to WKUserScripts (as in this PR).

So I think that the added friction (which is inconvenient but at least surmountable) should be weighed up against the fact that there is simply no way, using the old method, to inject JS into non-main frames.

[safaiyeh]

Sounds good, glad we got to talk about the pro/cons of these changes. I agree that the friction is warranted given the limitations & concerns.

Thanks for being very thorough with all of your responses @shirakaba! You've been super helpful helping me understand the changes and thank you for creating this PR.

I tested your changes on my production app and everything was smooth.

Will prep the Android PR for injectedJavaScriptBeforeContentLoaded, so we can merge these in at the same time.

[shirakaba]

@rekmarks 不用谢！

All tests pass :) requesting review now.

EDIT: One moment, looks like I was using an old version of the tests (thus, the tests were failing, due to the tests themselves being faulty)... need to commit the updated tests first.

[safaiyeh]

Awesome @shirakaba going to build it on my lunch break then approve if all goes well :)

[safaiyeh]

@shirakaba Could you add this to the docs: #1119 (comment)

"Retaining the behavior of collecting a JS evaluation value after injectedJavaScript" so people understand migration steps needed.

[safaiyeh]

Verified it worked! Just pending adding the migration docs and I'll land this as v9

[shirakaba]

@safaiyeh Thanks for building and testing!

As alluded to in my hasty edit, I've updated the test (the one you've run is my older, broken test). This one's more thorough (and more importantly, not broken):

For some reason, injection into iframes upon the beforeContentLoaded timepoint isn't working. As this mirrors the general behaviour of the Android implementation, it may simply be that my understanding has been wrong all along and we're looking at a WebKit limitation. By that reasoning, beforeContentLoaded may refer to window.top.document rather than each frame's window.self.document, so maybe the iframes don't exist at this point so we wouldn't expect them to be injectable beforeContentLoaded anyway.

Verified it worked! Just pending adding the migration docs and I'll land this as v9

Good idea – I'll get on that next.

[safaiyeh]

That makes sense that the frames do not exist before content is loaded; therefore, nowhere to inject into! Since this would bring Android & iOS parity, all the better.

I'll check out your updates

[shirakaba]

@safaiyeh Docs updated.

[safaiyeh]

Landed! @shirakaba thank you so much for your persistence from start to end. ❤️

[react-native-community-bot]

🎉 This PR is included in version 9.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[rekmarks]

I feel pampered, lol. Thanks guys! 🙌

[shirakaba]

Thank you @safaiyeh for the review and merge, and @rekmarks for the motivation!

[redpandatronicsuk]

This PR brakes injectedJavaScript for me, I opened an issue here: #1260

[jamninetyfive]

@shirakaba not work in lastest