Summary:**Motivation:** In my app, I'm using a WebView that loads content from my mobile site. What I want to do is when a user presses a link on the loaded page, I want to stop the WebView's request, hijack the URL and open the URL in a new WebView, pushed to the top of the navigator stack. To me, this gives the overall app a more native feel, instead of implementing a rudimentary navbar on the main WebView to go back.
**Attempted Workarounds:** I've attempted to get similar functionality by capturing the onNavigationStateChange event in the WebView, and then within calling goBack + pushing the new view to the navigator stack. From a functionality standpoint, this works. However, from a UI standpoint, the user can clearly see the webview change states to a new page + go back before having the new view pushed on top of their nav stack.
Closes https://github.com/facebook/react-native/pull/6886
Differential Revision: D3212447
Pulled By: mkonicek
fb-gh-sync-id: 05911e583d9ba54ddbd54a772153c80ed227731e
fbshipit-source-id: 05911e583d9ba54ddbd54a772153c80ed227731e
Summary:On iOS, `WebView` will get stuck when the first request fails to load. The most common case where this could happen is when a user has limited or no connectivity.
Here's a repo with a sample app that demonstrates the problem and this fix: [https://github.com/jballer/react-native-webview-reload-example](https://github.com/jballer/react-native-webview-reload-example).
**Attempted workarounds**
- `WebView.reload()` fails internally because the `UIWebView`'s `currentRequest` doesn't have its `URL` set
- Setting `WebView.source.uri` won't do anything; the JS value value is unchanged and therefore doesn't cross the native bridge.
- Unmounting and remounting the `WebView` component would lose history and context if an error occurs on a request that's not the first request.
**Test plan (manual testing)**
1. Disable network connection
1. Relaunch application or reload JS
1. Enable network connection
1. Tap "reload" button
1. Observe whether page reloads
Closes https://github.com/facebook/react-native/pull/6873
Differential Revision: D3159219
Pulled By: javache
fb-gh-sync-id: 8893dd20dc9f4a1a00d14a488ce657cc50287a29
fbshipit-source-id: 8893dd20dc9f4a1a00d14a488ce657cc50287a29
Summary: The exportedConstants method incurrs a penalty at bridge startup time for every module that implements it. This diff removes exportedConstants from a few modules that don't really need to use it.
Reviewed By: majak
Differential Revision: D2982341
fb-gh-sync-id: be016187d7b731a073311daacfcf88a0402e1688
shipit-source-id: be016187d7b731a073311daacfcf88a0402e1688
Summary: Fixed broken scaling logic in Webview example for iOS. Pages must be reloaded after toggling `scalesPageToFit`, but that wasn't happening.
Reviewed By: javache
Differential Revision: D2982371
fb-gh-sync-id: 8442609179bfe9ade10d1d0bac1807e4a8855d00
shipit-source-id: 8442609179bfe9ade10d1d0bac1807e4a8855d00
Summary:
public
https://github.com/facebook/react-native/pull/5494 added a new `source` property to WebView on Android that provides a better API, as well as allowing for request headers to be set.
This diff ports that functionality over to iOS, so we can have a consistent API cross-platform.
I've also extended the API to include `method` (GET or POST) and `body` when setting the WebView content with a URI, and `baseUrl` when setting static HTML.
Reviewed By: javache
Differential Revision: D2884643
fb-gh-sync-id: 83f24494bdbb4e1408aa8f3b7428fee33888ae3a
Summary: public
Original github title: Exported a callback for native webview delegate method shouldStartLoadWithRequest
We have a requirement in our app, to open in mobile Safari, any http:// and https:// links displayed in a web view. Our web view is not full screen and is loaded with an HTML string from the backend. Displaying external content in that web view is outside of the scope of our app, so we open them in mobile Safari.
I've forked the WebView component and added a callback property, shouldStartLoadWithRequest, and modified the RCTWebView implementation of `webView:shouldStartLoadWithRequest:navigationType:`
to check if the shouldStartLoadWithRequest property is set.
If the property is set, `webView:shouldStartLoadWithRequest:navigationType:` passes the URL & navigationType to the callback. The callback is then able to ignore the request, redirect it, open a full screen web view to display the URL content, or even deep link to another app with LinkingIOS.openURL().
Original author: PJ Cabrera <pj.cabrera@gmail.com>
Closes https://github.com/facebook/react-native/pull/3643
Reviewed By: nicklockwood
Differential Revision: D2600371
fb-gh-sync-id: 14dfdb3df442d899d9f2af831bbc8d695faefa33
Summary: We have a use case in the development of our app, where we are rendering some HTML content in a web view. But this content comes from the back end, and varies in height. There are other components on the page, so it's not a full screen web view. We need to dynamically alter the web view height, to fit the HTML content without scrolling, and to push the non-web view content on the screen down.
The solution I came up with, was to use the _loadingFinish callback, to send the evaluation of the injectedJavaScript property back to the React Native side. In my example above, injecting 'document.getElement(elementId).offsetHeight' evaluates to the height of the element, with margins and borders applied, and once returned to the RN app, it can change the app state and cause the web view height to be adjusted.
Closes https://github.com/facebook/react-native/pull/2753
Reviewed By: svcscm
Differential Revision: D2578688
Pulled By: mkonicek
fb-gh-sync-id: fc9c0d0f84994a409e037016a555534549f8957a
Summary:
Currently, the system for mapping JS event handlers to blocks is quite clean on the JS side, but is clunky on the native side. The event property is passed as a boolean, which can then be checked by the native side, and if true, the native side is supposed to send an event via the event dispatcher.
This diff adds the facility to declare the property as a block instead. This means that the event side can simply call the block, and it will automatically send the event. Because the blocks for bubbling and direct events are named differently, we can also use this to generate the event registration data and get rid of the arrays of event names.
The name of the event is inferred from the property name, which means that the property for an event called "load" must be called `onLoad` or the mapping won't work. This can be optionally remapped to a different property name on the view itself if necessary, e.g.
RCT_REMAP_VIEW_PROPERTY(onLoad, loadEventBlock, RCTDirectEventBlock)
If you don't want to use this mechanism then for now it is still possible to declare the property as a BOOL instead and use the old mechanism (this approach is now deprecated however, and may eventually be removed altogether).
Summary:
Our events all follow a common pattern, so there's no good reason why the configuration should be so verbose. This diff eliminates that redundancy, and gives us the freedom to simplify the underlying mechanism in future without further churning the call sites.
Summary:
Android WebView now supports the prop "injectedJavaScript", too.
It's time to rename "injectedJavascriptIOS" to "injectedJavaScript" for API
consistency between IOS and Android.
Summary:
@public
The API and implementation of `shouldInjectAJAXHandler` is very opinionated, and it does not solve many of the use cases that we'd like to address.
Since `shouldInjectAJAXHandler` is basically juts injecting JS to the web page, we should let developer inject whatever JS that address different issues that they want to fix.
Test Plan:
Test this snippet at <Playground />
```
<WebView
url="http://www.facebook.com"
injectedJavascriptIOS="document.body.style.border='solid 10px red'"
/>
```
Summary:
@public
I've increased the warning levels in the OSS frameworks, which caught a bunch of minor issues. I also fixed some new errors in Xcode 7 relating to designated initializers and TLS security.
Test Plan:
* Test the sample apps and make sure they still work.
* Run tests.
Summary:
Enables overwriting of underlying colors for WebViews. Especially useful if you want to give your WebView a transparent background.
Closes https://github.com/facebook/react-native/pull/767
Github Author: Lochlan Wansbrough <lochie@live.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Summary:
Allows setting of HTML directly on webview to support #506. This is a starting point, and feedback/improvement is requested.
1. if `startInLoadingState` is true, the HTML content will never show since the load event never fires
2. Neither html nor url are set as required props any more
Closes https://github.com/facebook/react-native/pull/542
Github Author: Colin Ramsay <colinramsay@gmail.com>
Test Plan: Imported from GitHub, without a `Test Plan:` line.
Andrew Gray
Jonathan Ballerano
Nick Lockwood
tuyou
Pieter De Baets
PJ Cabrera
Alexey Lang
Hedger Wang
Lochlan Wansbrough
Colin Ramsay
Tadeu Zagallo