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.
Pieter De Baets
PJ Cabrera
Alexey Lang
Nick Lockwood
Hedger Wang
Lochlan Wansbrough
Colin Ramsay
Tadeu Zagallo