Summary:
Currently, `onLoadStart` fires for a couple of cases:
1. toplevel page loads (e.g. initial page load, clicking links)
2. loading of pages within an iframe
The fact that `onLoadStart` fires for case (2) causes some problems. For example, it makes it difficult for the code that uses the WebView to know what URL the WebView is currently rendering. This is because the listener can't distinguish between the toplevel URL and the URL of an iframe. Additionally, this behavior is inconsistent with the behavior on iOS. On iOS, `onLoadStart` only fires for toplevel page loads.
To fix these issues, this change deletes the `doUpdateVisitedHistory` handler so that `onLoadStart` only fires for case (1).
**Test Plan**
Created a test page that has an iframe and loaded it in the WebView. Verified that `onLoadStart` only fires for toplevel page loads.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/15554
Differential Revision: D5665979
Pulled By: hramos
fbshipit-source-id: a52e473bc5691a6e180f45f0728e4ad89a7d354f
Summary:
This is a workaround for missing PDF url support in Android WebView, which is a general known issue: when tapping a PDF url within WebView, instead of doing nothing, we just let android default intent handle it (e.g. it will open Chrome to load it).
This is basically to trick `shouldOverrideUrlLoading()` to return true for the specific url. The drawback is that product code needs to provide the whitelist.
The proper fix would be to use PdfRenderer in that method, but it seems like it's only for API >= 21...
Differential Revision: D5619383
fbshipit-source-id: f86b930f970dab9a5f57999df69ce94b9508edc9
Summary:
…cookies on Android Lollipop or later versions.
Third party cookies in WebView are [disabled by default](https://developer.android.com/reference/android/webkit/CookieManager.html#setAcceptFileSchemeCookies(boolean)) on Android Lollipop or later versions. This prevented users from logging in by using _Login by Facebook_ method (in redirect mode) in Android Webview.
This PR exposes a prop `thirdPartyCookiesEnabled` which will enable third party cookies in Android Webview. This setting is ignored on versions below Android Lollipop and on iOS as third party cookies are enabled in them by default.
Appropriate documentation was added in code and they were reflected in the website.
Closes https://github.com/facebook/react-native/pull/14013
Differential Revision: D5145059
Pulled By: shergin
fbshipit-source-id: 67bcb3a497a9c6f6db1d12e8d16197d2facd157e
Summary:
On some devices, we saw many Chrome windows open when the WebView attempted to send the user to about:blank. This change allows the WebView to handle about:blank which prevents the Chrome windows from opening and gives the user a better experience.
Verified that the WebView no longer opens the device's browser when navigating to about:blank. My team has been using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14173
Differential Revision: D5142352
Pulled By: hramos
fbshipit-source-id: 1070d4381b385a5bf1829fd8e97efba2045f7968
Summary:
Adds functionality to be able to disable saving of form data and thereby disabling autocomplete in webview on Android. Can be used as a workaround for #13241
Manual testing that autocomplete is disabled when the property is set to true, and still enabled when it is unset or set to false.
Closes https://github.com/facebook/react-native/pull/13271
Differential Revision: D4858899
Pulled By: ericvicenti
fbshipit-source-id: 62738b0685e4c1958c8a32e184fa2fe4f711b336
Summary:
PR for option to set mixed content mode in Webview(Android) for issue #8460
Closes https://github.com/facebook/react-native/pull/12314
Differential Revision: D4663084
Pulled By: lacker
fbshipit-source-id: 0e40ea463739166311ddcb7887ff6d0289369637
Summary: We're logging all console logs from webview. This strips console logging for non debug builds
Reviewed By: AaaChiuuu
Differential Revision: D4578071
fbshipit-source-id: 79b21012a6ef215eb35701911662a720cb6be280
Summary:
Many websites use domstorage and never think of its unavailability, which usually leads to a blank page on android and hard for developers to debug. I think it's better to enable domstorage by default, for convenience and consistency to iOS and PC.
Closes https://github.com/facebook/react-native/pull/11333
Differential Revision: D4437165
Pulled By: hramos
fbshipit-source-id: a00441cb5214cca27927471d3a33f030b9ff9b52
Summary:
Currently, < WebView > allows you to pass JS to execute within the view. This works great, but there currently is not a way to execute JS after the page is loaded. We needed this for our app.
We noticed that the WebView had messaging support added (see #9762) . Initially, this seemed like more than enough functionality for our use case - just write a function that's injected on initial load that accepts a message with JS, and `eval()` it. However, this broke once we realized that Content Security Policy can block the use of eval on pages. The native methods iOS provide to inject JS allow you to inject JS without CSP interfering. So, we just wrapped the native methods on iOS (and later Android) and it worked for our use case. The method injectJavaScript was born.
Now, after I wrote this code, I realized that #8798 exists and hadn't been merged because of a lack of tests. I commend what was done in #8798 as it sorely solves a problem (injecting JS after the initial load) and has more features than what I'
Closes https://github.com/facebook/react-native/pull/11358
Differential Revision: D4390425
fbshipit-source-id: 02813127f8cf60fd84229cb26eeea7f8922d03b3
Summary:
When tapping on a link in a WebView with an unknown scheme, the app would crash. For example, if you have the link "something://example/" but your device doesn't have anything to handle the "something" scheme, the app would crash when the user clicks on the link. This change handles the exception to prevent the app from crashing. Instead, the click is a no-op and the WebView doesn't navigate anywhere.
**Test plan (required)**
Verified the app no longer crashes when clicking on unknown schemes in a test app. Also, my team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10903
Differential Revision: D4226371
Pulled By: mkonicek
fbshipit-source-id: a6d3957806c6063e74fe055b0979cb9d1ce40e51
Summary:
This pull request exposes the `setAllowUniversalAccessFromFileURLs` method of Android WebViewSettings as a property. The reason for this is when loading pages with a `file://` baseUrl it's sometimes desirable to allow loading other assets from a file base url. (For example loading an image into a canvas). More information on its use and purpose can be found [in the android docs here](https://developer.android.com/reference/android/webkit/WebSettings.html#setAllowUniversalAccessFromFileURLs%28boolean%29)
Usage example:
``` jsx
return (
<WebView
source={{ html: myhtml, baseUrl: 'file://' }}
allowUniversalAccessFromFileURLs={true}
javaScriptEnabled={true} />
)
```
Closes https://github.com/facebook/react-native/pull/8905
Differential Revision: D4147245
Pulled By: hramos
fbshipit-source-id: 7eaa884b8c0268de52b284954a34acec0fbd4061
Summary:
Followup for #5822, addressing nits.
**Test Plan**
Travis CI (the author of #5822 tested the change).
Closes https://github.com/facebook/react-native/pull/10563
Differential Revision: D4081826
fbshipit-source-id: f3a2e1996bf02f81fecea6e53fe1c522b8c85689
Summary:
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.
Closes https://github.com/facebook/react-native/pull/9762
Differential Revision: D4008260
fbshipit-source-id: 84b1afafbc0ab1edc3dfbf1a8fb870218e171a4c
Summary:
When using webview on android and trying to link to an html file located on device (using `file://`), the application would crash with an error specifying that nothing handles the fired intent. This is due to [`33a1f28`](33a1f28654) which attempts to intercept all non `http(s)` links.
This is a simple fix so hopefully it can make it into the next stable release.
Closes https://github.com/facebook/react-native/pull/9668
Differential Revision: D3956485
fbshipit-source-id: 5a752abc21802a44e3a26e88669ccb6852076992
Summary: Added support for WebViews to take in an onContentSizeChange prop, which will return a native event that contains the width and height of the html content in the WebView. Also moved the ContentSizeChangeEvent from the recyclerview dir to the uimanager/events dir
Reviewed By: andreicoman11
Differential Revision: D3775399
fbshipit-source-id: 19a0579f8345e5853cc7311b80f1f1393c77ab58
Summary:
Because it is react, the url could be changed on redirection or some other ways.
The iOS version's WebView has controled that on [here](https://github.com/facebook/react-native/blob/master/React/Views/RCTWebView.m#L106).
But the Android's one is not.
Check the url is same with privous url. If it is true, cancel loading.
This logic is same with iOS's.
the ```method``` hasn't compared.
Test urls as we can.
The Google Map(https://map.google.com) was one of the site which has occur error before this commit.
related issue : #9121
Closes https://github.com/facebook/react-native/pull/9126
Differential Revision: D3663685
Pulled By: javache
fbshipit-source-id: f38c9012ee077677543dafcea83c0778a4471bfa
Summary:
Supersedes PR #8536Fixes#5211
JavaScript plugins such as Fotorama are broken when attempting use its fullscreen feature.
If there's an absolute HTML element with 100% height under <body>, its height is 0 when rendered in the Android WebView.
This commit fixes it.
Closes https://github.com/facebook/react-native/pull/8830
Reviewed By: bestander
Differential Revision: D3632821
Pulled By: jamesgpearce
fbshipit-source-id: c185bcd30d1d214a357d0d8552d61d0ddfa5e6c6
Summary: This is pure cleanup so that we can make sure that all events are living in the same time space (currently nano seconds).
Reviewed By: foghina
Differential Revision: D3593884
fbshipit-source-id: 71b084362008f1c93c21880630acf11f5c058355
Summary:
Makes sure request for geolocation use in the webview is handled.
This solves issue #7609
Currently use of geolocation in webview fails silently, as the permission request is never received by the native app.
**Test plan (required)**
1. Create new project with webview
2. Add javascript for geolocation:
```javascript
navigator.geolocation.getCurrentPosition(function (position) {
console.log('success', position)
}, function (error) {
console.log('could not determine position', error)
})
```
3. Run code and assert geolocation permission is requested, resulting in success (or error) callback being called
Closes https://github.com/facebook/react-native/pull/8305
Differential Revision: D3592887
fbshipit-source-id: 84fe2383fba8873431c5e89d154c0a4fd58ffb70
Summary:
So `PanReponder.onPanResponderRelease/onPanResponderTerminate` receive a `gestureState` object containing a `onPanResponderTerminate.vx/vy` property. On Android and iOS, they appear to be orders of magnitude different, which appear to be due to the different scale of timestamps that are used when generating touch events.
This pull request fixes the timestamps to be milliseconds on both platforms (since I assume iOS is the more authoritative one, and is the one that `react-native-viewpager`'s vx thresholds written written to compare against.)
As far as I can tell, the RN code doesn't use the `vx/vy` properties, so they should be okay. And looks like the RN code only cares about relative values of `startTimestamp/currentTimestamp/previousTimestamp` though, so should be fine too. it's quite possible there will be downstream android breakage with this change, particularly for those who are already compensating for the RN discrepancy.
Closes https://github.com/facebook/react-native/pull/8199
Differential Revision: D3528215
Pulled By: davidaurelio
fbshipit-source-id: d81732e50a5ece2168e8347309d8d52a0db42951
Summary:
So `PanReponder.onPanResponderRelease/onPanResponderTerminate` receive a `gestureState` object containing a `onPanResponderTerminate.vx/vy` property. On Android and iOS, they appear to be orders of magnitude different, which appear to be due to the different scale of timestamps that are used when generating touch events.
This pull request fixes the timestamps to be milliseconds on both platforms (since I assume iOS is the more authoritative one, and is the one that `react-native-viewpager`'s vx thresholds written written to compare against.)
As far as I can tell, the RN code doesn't use the `vx/vy` properties, so they should be okay. And looks like the RN code only cares about relative values of `startTimestamp/currentTimestamp/previousTimestamp` though, so should be fine too. it's quite possible there will be downstream android breakage with this change, particularly for those who are already compensating for the RN discrepancy.
Closes https://github.com/facebook/react-native/pull/8199
Differential Revision: D3528215
Pulled By: dmmiller
fbshipit-source-id: cbd25bb7e7bb87fa77b661a057643a6ea97bc3f1
Summary: Make the behavior on a WebView allow pinch to zoom. This matches what iOS has by default. We may want to at some point put this behind a property but right now just make it work on Android.
Reviewed By: andreicoman11
Differential Revision: D3503429
fbshipit-source-id: adb2bb2c3de099aca08700786be7a132557a5e2a
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:Remove Trailing Spaces.
Why:
Sometimes there are conflicts with trailing spaces
Saves space
Those whose tools automatically delete them will have their pr watered down with trailing space removal
Closes https://github.com/facebook/react-native/pull/6787
Differential Revision: D3144704
fb-gh-sync-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
fbshipit-source-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
Summary:Just added a pass through to the `WebView` for `mediaPlaybackRequiresUserAction` and `setMediaPlaybackRequiresUserGesture` to allow auto-playing audio and video elements
Closes https://github.com/facebook/react-native/pull/5956
Differential Revision: D3053554
Pulled By: mkonicek
fb-gh-sync-id: a1f362c1551de1a0218f5d23c70668e4c8078993
shipit-source-id: a1f362c1551de1a0218f5d23c70668e4c8078993
Summary:PR for https://github.com/facebook/react-native/issues/5958. The viewport meta tags if present, are overridden from the page and it is rendered according to the screen size. An example has been added in the Web View section of UIExplorer demo app.
Closes https://github.com/facebook/react-native/pull/6013
Differential Revision: D2953940
Pulled By: nicklockwood
fb-gh-sync-id: 012769f3a2a3f7dc942b60de02a9d1b80a27236e
shipit-source-id: 012769f3a2a3f7dc942b60de02a9d1b80a27236e
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:
Related to [issue #5418](https://github.com/facebook/react-native/issues/5418)
This is a follow-up to [this previous pull request.](https://github.com/facebook/react-native/pull/5419)
~~Adds a new ReactProp 'urlWithHeaders' to Android WebViews that takes an object with a 'url' string and a 'headers' map.~~
[Update] Adds a new prop 'source' to Android WebViews
```
{
html: string,
url: string,
headers: map<string, string>,
}
```
Update: resolves TODO 8495359
Closes https://github.com/facebook/react-native/pull/5494
Reviewed By: svcscm
Differential Revision: D2881313
Pulled By: nicklockwood
fb-gh-sync-id: 7cad8490d4932d0a7ef559165f3ec279d873c537
Summary:
Moves ReactProp and ReactPropGroup to `com.facebook.react.uimanager.annotations`. This is needed
so that future annotation processor can run on code inside the com.facebook.react.uimanager package.
public
Reviewed By: astreet
Differential Revision: D2754842
fb-gh-sync-id: 3808c3e3f6c45e5897ecab88cd4175573c0c24e6
Summary:
2 things that I want to clarify / ask for feedback:
* do we really need to make sure we're running on the UI thread? I guess `onPageStarted` maybe already runs there? Couldnt find anything [here](http://developer.android.com/reference/android/webkit/WebView.html) though
* everytime a page starts we re-enable debugging -- it's a bit useless but I also don't think it's a huge problem, as debugging should only be enabled in dev
Relates to issue #4857, where we switched debugging off as, in some circumstances, it would crash the application as debugging was invoked outside the UI thread.
Closes https://github.com/facebook/react-native/pull/5071
Reviewed By: svcscm
Differential Revision: D2803649
Pulled By: astreet
fb-gh-sync-id: 523d3b442b196d6c54b14ba0c2b29601095c3363
Summary:
Was developing on a WebView and couldnt get it to run. Turns out its JS code mostly depends on `localStorage` and I realized it wasnt turned on in RN. This PR adds a prop, similar to `javascriptEnabledAndroid` to be able to turn DOM storage on / off.
TBH I dont really know how it works on IOS, so I created an android specific thingy. I assume DOM storage is enabled by default on IOS.
Closes https://github.com/facebook/react-native/pull/5065
Reviewed By: svcscm
Differential Revision: D2797735
Pulled By: androidtrunkagent
fb-gh-sync-id: cd60cfa4d24d80fb82e4f54f387a4517a99e75ab
Summary:
`WebView.getUrl()` doesn't return the correct value in WebView callbacks
(e.g. `onPageFinished`).
For example, when navigating to a URL, we report that loading finished,
but still with the old URL. This diff fixes that.
public
Reviewed By: andreicoman11
Differential Revision: D2769597
fb-gh-sync-id: f14bdd405290469ac0a20d0fb89aa2a27d33e758
