[jacobp100]

JS API very similar to web workers and node's child process.

Work has been done by somebody else for the Android implementation over at #7020, so we'd need to have these in sync before anything gets merged.

I've made a prop messagingEnabled to be more explicit about creating globals—it might be sufficient to just check for an onMessage handler though.

[ghost]

By analyzing the blame information on this pull request, we identified @spicyj and @caabernathy to be potential reviewers.

[eslint-bot]

object literal This type is incompatible with undefined. Did you forget to declare type parameter State of property Component?

[ghost]

@jacobp100 updated the pull request - view changes

[eslint-bot]

react/no-string-refs: Using this.refs is deprecated.

[ghost]

@jacobp100 updated the pull request - view changes

[facebook-github-bot]

@jacobp100 updated the pull request - view changes

[eslint-bot]

call of method postMessage Method cannot be called on possibly null value null

[ghost]

@jacobp100 updated the pull request - view changes

[eslint-bot]

curly: Expected { after 'if' condition.

[ghost]

@jacobp100 updated the pull request - view changes

[ghost]

@jacobp100 updated the pull request - view changes

[mkonicek]

Thanks for the PR! It's very large so might take some time to review. I asked about opinions here as I don't use WebView: https://www.facebook.com/groups/reactnativeoss/permalink/1588566434773318

[mkonicek]

@jacobp100 If we go ahead with this approach it will be possible to implement the exact same API on Android, correct? Would you be up for doing that after or do you know anyone who would? :)

[mkonicek]

Let's wait if someone with iOS experience jumps in to review - I have little.

[fungilation]

I'm looking at this in 0.37. I'm using
https://github.com/alinz/react-native-webview-bridge. This looks like a
complete replacement?

On Tue, Nov 8, 2016 at 5:32 AM David Perrenoud notifications@github.com
wrote:

Now available in React Native v0.37.0
https://github.com/facebook/react-native/releases/tag/v0.37.0!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9762 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADoJSpkxcZVc6m-ozE01bXJ7TEgkuVvbks5q8HnmgaJpZM4J1o5Z
.

[jacobp100]

You’ll have to change the webview’s JS a little, but otherwise it works the same.

[bengoism]

I keep getting the following error:

"Setting onMessage on a WebView overrides existing values of window.postMessage, but a previous value was defined".

How do I handle the scenario where the visited webpage already has a declared a window.postMessage function?

[mlostekk]

@jacobp100 can you explain which JS changes have to be made?

[jacobp100]

You should be able to use injectedJavaScript=“window.postMessage = null”.

[mlostekk]

I am trying to re-implement this example here

https://facebook.github.io/react-native/docs/webview.html

but i cannot find the file

messagingtest.html

from

source={require('./messagingtest.html')}

Can you post the content here?

[bengoism]

@jacobp100: But after assigning null to window.postMessage I get the following error when trying to send a message window.postMessage is not a function, window.postMessage is null .. which kinda makes sense since my injected javscript in short looks like this

window.postMessage = null;
...
window.postMessage("hello");

[bengoism]

@mlostekk
https://github.com/facebook/react-native/blob/abb8ea3aea686e2cd881a61fbc66d137857ef422/Examples/UIExplorer/js/messagingtest.html

[jacobp100]

@bengoism

window.postMessage = null;
setTimeout(() => { window.postMessage(‘hello’); });

It might be worth revisiting this. My view was just that we should override the value, and document that behaviour.

[bengoism]

@mlostekk:

Basically you should change the following on the client

window.WebViewBridge.send("hello"); 
to 
window.postMessage("hello")

  window.WebViewBridge.onMessage = function(message) {
    alert(message);
  }
  to 
  document.addEventListener('message', function(event){
    alert(event.data)
  })

[fungilation]

I'm constantly getting:
Setting onMessage on a WebView overrides existing values of window.postMessage, but a previous value was defined

I have window.postMessage = null; as the first line in WebView.injectedJavaScript. The error shows up after form submission and page reloads. Initial page load is fine in the WebView.

Is there a way around this, or is this a bug? The error seems self contradictory anyway. If there is a previous value of postMessage, it would/should be overridden as the error says. But if it is, why is there the error in the first place if postMessage is simply replaced?

[malinthe]

I'm also constantly getting the Setting onMessage on a WebView overrides existing values of window.postMessage, but a previous value was defined error message, but this only happens when there's an iframe embed in the html view. Any idea why?

[jacobp100]

See #10941

[fungilation]

This is better. Though why overlap and break pages that already use window.postMessage, when RN can use a different name? Say, window.rnPostMessage. Then this issue of namespace collision is sidestepped, and original webpages that uses window.postMessage can load on page without breakage.

Otherwise, we could inject JS to run at precise the right moment (right after postMessage got moved to originalPostMessage), just to undo this RN behaviour by:

window.rnPostMessage = window.postMessage
window.postMessage = window.originalPostMessage

This would seem counter-productive at best, if not prone to breakage still as the above would need to be run at precisely the right moment after RN's replacement of window.postMessage? Original page's code would break if it calls window.postMessage that's RN's replacement instead of the real original.

[satya164]

Since people are having issues now, how about revisiting the decision and doing something like this?

window.postMessage = function(message, targetOrigin, transfer) {
  if (targetOrigin != 'self') {
    window.originalPostMessage(message, targetOrigin, transfer);
  }
  bridge.postMessage(message);
}

i.e. always requiring targetOrigin to be specified. At least it'll not be hacky like current workarounds.

[satya164]

Though why overlap and break pages that already use window.postMessage, when RN can use a different name

#9762 (comment)

We don't have to break pages really. It's just the current implementation.

[mkonicek]

Can anyone running into issues submit a PR with a fix? We don't use this API internally so can't provide much feedback.

[jacobp100]

Can all issues be added to #10941, and this PR be closed from further comments?