* Update RNCWebView.h

Limit methods relating to pull to refresh to only iOS

* Update RNCWebView.m

Block methods relating to pull to refresh when the target is macOS as macOS does not have the UIRefreshControl

Co-authored-by: Eloy Durán <eloy.de.enige@gmail.com>

Co-authored-by: Jamon Holmgren <jamon@infinite.red>
Co-authored-by: Jamon Holmgren <jamonholmgren@gmail.com>
Co-authored-by: Thibault Malbranche <thibault.malbranche@epitech.eu>

Co-authored-by: Cristiano Coelho <cristianocca@hotmail.com>

* Add pull to refresh support for iOS

* Add pull to refresh control removal from WebView

* Add the type and reference description about pull to refresh

* Set bounces to true when enabling pull to refresh, add references

* Add the back to props anchor to pullToRefreshEnabled

* Add isTopFrame to shouldStartLoadForRequest on iOS

onLoadingStart is not raised for inner frames, but onShouldStartLoadWithRequest still is. This keeps that behavior but adds isTopFrame to onShouldStartLoadWithRequest so that apps can perform their own filtering if desired.

* Update docs

Co-authored-by: Jamon Holmgren <jamonholmgren@gmail.com>

This allows overriding iPadOS 13's desktop-class browsing to load mobile content instead of desktop content.

Co-authored-by: Jamon Holmgren <jamonholmgren@gmail.com>

* fix(iOS): Consider UIImagePickerController or similar controllers that are no longer beingPresented when acquiring the TopViewController; this prevents the crash of throwing an alert on a ViewController which is no longer in the window hierarchy

* fix(iOS): correcting import to src from lib

* fix(iOS): reverting import modification

Co-authored-by: Thibault Malbranche <thibault.malbranche@epitech.eu>

[skip ci]

[skip ci]

`onFileDownload` is called with the URL that you can use to download the file.
When RNCWebView detects that the HTTP response should result in a file download,
`onFileDownload` is called. The client can then provide code to download
the file.

RNCWebView determines that a file download should take place if either of the
following is true:
1. The HTTP response contains a `Content-Disposition` header that is of type
  'attachment'
2. The MIME type of the response cannot be rendered by the iOS WebView

* [apple] Move iOS/macOS src into common apple dir

* [apple] Enable macOS as platform in podspec

* [example] Use CocoaPods & auto-linking on macOS

* [docs] Update setup for macOS

* [package] Include apple dir in distribution

* Fixes Issue #1140

Fixes https://github.com/react-native-community/react-native-webview/issues/1140
Based on a solution found at: https://stackoverflow.com/questions/56460362/how-to-force-wkwebview-to-ignore-hardware-silent-switch-on-ios
I changed the code found in the linked source from Swift to Objective-C, as required by this project. WARNING: I haven't used Swift before and very limited experience with Objective-C.

- For me this seems to work, but it is not the cleanest solution in my opinion.
- It might also be possible to play generated sound (i.e. using oscillator) instead of hardcoding the silent base64 mp3 data.
- Maybe ignoring silence switch should only be done if a parameter is supplied

* fixes import path

* adds documentation for ignoreSilentHardwareSwitch

* adds ignoreSilentHardwareSwitch parameter

* reverting back to old import path

* Update Guide.md

Co-authored-by: Dominik Beste <dominik.beste@gmail.com>

BREAKING CHANGE: 
• Props updates to `injectedJavaScript` are no longer immutable.

• `injectedJavaScript` no longer attaches a `jsEvaluationValue` property to the `onLoadingFinish` event. Check out: https://github.com/react-native-community/react-native-webview/pull/1119#issuecomment-574919464 to migrate with the same behavior.

BREAKING CHANGE: if you use onNavigationStateChange on iOS it will now trigger on # changes to the url.

* Hook the `window.history` API on iOS to generate events

The underlying WKWebView doesn't seem to generate any events in response to the `window.history` API - none of the `WKNavigationDelegate` methods fire.

Given this limitation, the only way to know when the location changes via this API is to inject Javascript into the page and have it notify the native code directly when any of these functions are called.

The `setTimeout` call gives up the current tick, allowing the location to change before firing the event.

* Remove the outdated section about hash changes

Now that this bug is fixed, the workaround is no longer required.

* Run the injectedJavaScript on DocumentStart for iOS

* Add new prop injectedJavaScriptBeforeContentLoaded
Update types
Update docs

* Self review

UIWindowDidBecomeVisibleNotification and UIWindowDidBecomeHiddenNotification seem far more reliable at detecting fullscreen video.

Tested on iOS 11, 12 and 13

* Fix Xcode warnings (enums, whitespace, string literals)

* Add nullability notations

* Add callback for WKWebView's onContentProcessDidTerminate

* Add platform information to docs

* Add new WebViewTerminatedEvent type

* Allow custom CA to be used on webview requests

* Add documentation and an example for Custom CA / SSL Pinning

* fix inconsistent backgroundColor

* remove redundant setBackgroundColor

* fix(ios):use RCTConvert to convert url instead of using URLWithStringg

* fix(iOS):remove stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding, because it's deprecated in iOS 9

Apple required us to remove this (see #819)

BREAKING CHANGE: UIWebView has been removed
BREAKING CHANGE: useWebkit prop removal
BREAKING CHANGE: scalesPageToFit prop removal on iOS (since it's not compatible with WKWebview)
BREAKING CHANGE: Renamed RNCWKWebView to RNCWebView on iOS

* add-javaScriptEnabled-in-IOS

* Update WebViewTypes.ts

* Adding a `contentInsetAdjustmentBehavior` prop to the WebView for iOS.
This controls the way iOS will automatically adjust the insets when the
webview is behind things like the iPhone X notch.

* Removing the code to explicitly pass contentInsetAdjustmentBehavior to the WebView since it is already passed in otherProps.

* Changes error/redbox into warning/yellowbox. So wouldn't crash production releases
* Warning added actual error, useful for debugging bad JS injected into webview
* callback runs, whether there's error or not. As used in my app (https://medium.com/wonderswipe/rethink-mobile-search-10-100x-faster-introducing-wonderswipe-6f2ff0d0e6) which injects JS into sanitized html from the wild, small error in injected JS doesn't warrant the whole JS payload from being injected/run

* Pass mainDocumentURL to onShouldStartLoadWithRequest

* Update reference

* Update typescript types

* Update WebViewTypes.ts

* Add `onScroll` callback for iOS & Android

This code was mostly extracted from https://github.com/react-native-community/react-native-webview/pull/202

I tried and tried to make it work with `Animated.event`'s `useNativeDriver`, but I was unsuccessful 😢 that'll have to be done later once I understand better how Animated's native stuff is hooked up.

* fix crash for missing onScroll

fixes #62

* [iOS] Allow focus without user interaction

* Add documentation for keyboardDisplayRequiresUserAction

* set keyboardDisplayRequiresUserAction default to true

We had the problem on iOS WebViews that local cookies (stored in local HTTPCookieStorage, set with  [react-native-cookie](https://github.com/shimohq/react-native-cookie) ) were not added in loadRequests. On Android the local stored cookies were sent like expected.
This kinda "hacky" solution is the only way we found, that works for us.
The stack overview link is in the code below.
If someone finds a better solution we would very much like to accept that.

fixes #371

* Don't allow the scrollview to scroll the WebView body.

* Readme comment

* Remove duplicate protocol def

This PR fixes two crashes when enableWebKit is true (which was the default) on iOS 9.x. The first one when the WebView component was mounted (fixes issue #150) and the second one, when the component was unmounted (fixes issue #213).

The first problem happen when the RNCWKWebView.m was loaded:

The programming guide for WebKit (version 2006) ([pdf](http://mirror.informatimago.com/next/developer.apple.com/documentation/Cocoa/Conceptual/DisplayWebContent/WebKit_DisplayWebContent.pdf)) from Apple said, that it is (was) required to check if the 'new' WebKit Framework was available. This was required when the WebKit framework was only available on Mac OS X (10.2) when the Safari was installed. 😆

Because WebKit is (currently..) a fix part of iOS we didn't need this check this anymore to determinate if WebKit is available. I also see no other reference that this is required in iOS so I just remove this code. Without this code the WebView works also on iOS 9.x.

The second issue happen when the WKWebView was removed from the native view hierarchy. Its required (only on iOS 9) to remove the UIScrollView delegate before cleaning up the webview.

Its possible to try this PR with:

```
npm install --save "react-native-webview@jerolimov/react-native-webview#fix-ios9-crash"
# or
yarn add "react-native-webview@jerolimov/react-native-webview#fix-ios9-crash"
```

If you use CocoaPods, you should also update your Pods with

```
cd ios && pod update && cd ..
```