2015-03-23 20:28:42 +00:00
|
|
|
/**
|
|
|
|
* Copyright (c) 2015-present, Facebook, Inc.
|
|
|
|
*
|
2018-02-17 02:24:55 +00:00
|
|
|
* This source code is licensed under the MIT license found in the
|
|
|
|
* LICENSE file in the root directory of this source tree.
|
2015-03-23 20:28:42 +00:00
|
|
|
*/
|
2015-03-14 08:22:25 +00:00
|
|
|
|
|
|
|
#import "RCTWebView.h"
|
|
|
|
|
|
|
|
#import <UIKit/UIKit.h>
|
|
|
|
|
|
|
|
#import "RCTAutoInsetsProtocol.h"
|
2016-02-02 02:00:18 +00:00
|
|
|
#import "RCTConvert.h"
|
2015-03-14 08:22:25 +00:00
|
|
|
#import "RCTEventDispatcher.h"
|
|
|
|
#import "RCTLog.h"
|
|
|
|
#import "RCTUtils.h"
|
|
|
|
#import "RCTView.h"
|
2015-03-26 09:58:06 +00:00
|
|
|
#import "UIView+React.h"
|
2015-03-14 08:22:25 +00:00
|
|
|
|
2015-07-02 01:06:39 +00:00
|
|
|
NSString *const RCTJSNavigationScheme = @"react-js-navigation";
|
2017-07-25 11:40:19 +00:00
|
|
|
|
|
|
|
static NSString *const kPostMessageHost = @"postMessage";
|
2015-07-02 01:06:39 +00:00
|
|
|
|
2015-03-14 08:22:25 +00:00
|
|
|
@interface RCTWebView () <UIWebViewDelegate, RCTAutoInsetsProtocol>
|
|
|
|
|
Added mechanism for directly mapping JS event handlers to blocks
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).
2015-09-02 12:58:10 +00:00
|
|
|
@property (nonatomic, copy) RCTDirectEventBlock onLoadingStart;
|
|
|
|
@property (nonatomic, copy) RCTDirectEventBlock onLoadingFinish;
|
|
|
|
@property (nonatomic, copy) RCTDirectEventBlock onLoadingError;
|
2015-11-04 16:42:28 +00:00
|
|
|
@property (nonatomic, copy) RCTDirectEventBlock onShouldStartLoadWithRequest;
|
2016-10-16 13:29:14 +00:00
|
|
|
@property (nonatomic, copy) RCTDirectEventBlock onMessage;
|
Added mechanism for directly mapping JS event handlers to blocks
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).
2015-09-02 12:58:10 +00:00
|
|
|
|
2015-03-14 08:22:25 +00:00
|
|
|
@end
|
|
|
|
|
|
|
|
@implementation RCTWebView
|
|
|
|
{
|
|
|
|
UIWebView *_webView;
|
2015-07-08 00:07:52 +00:00
|
|
|
NSString *_injectedJavaScript;
|
2015-03-14 08:22:25 +00:00
|
|
|
}
|
|
|
|
|
2016-01-27 10:49:12 +00:00
|
|
|
- (void)dealloc
|
|
|
|
{
|
|
|
|
_webView.delegate = nil;
|
|
|
|
}
|
|
|
|
|
Added mechanism for directly mapping JS event handlers to blocks
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).
2015-09-02 12:58:10 +00:00
|
|
|
- (instancetype)initWithFrame:(CGRect)frame
|
2015-03-14 08:22:25 +00:00
|
|
|
{
|
Added mechanism for directly mapping JS event handlers to blocks
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).
2015-09-02 12:58:10 +00:00
|
|
|
if ((self = [super initWithFrame:frame])) {
|
2015-04-21 01:01:46 +00:00
|
|
|
super.backgroundColor = [UIColor clearColor];
|
2015-03-14 08:22:25 +00:00
|
|
|
_automaticallyAdjustContentInsets = YES;
|
|
|
|
_contentInset = UIEdgeInsetsZero;
|
|
|
|
_webView = [[UIWebView alloc] initWithFrame:self.bounds];
|
|
|
|
_webView.delegate = self;
|
2017-10-31 06:06:11 +00:00
|
|
|
#if defined(__IPHONE_OS_VERSION_MAX_ALLOWED) && __IPHONE_OS_VERSION_MAX_ALLOWED >= 110000 /* __IPHONE_11_0 */
|
|
|
|
if ([_webView.scrollView respondsToSelector:@selector(setContentInsetAdjustmentBehavior:)]) {
|
|
|
|
_webView.scrollView.contentInsetAdjustmentBehavior = UIScrollViewContentInsetAdjustmentNever;
|
|
|
|
}
|
|
|
|
#endif
|
2015-03-14 08:22:25 +00:00
|
|
|
[self addSubview:_webView];
|
|
|
|
}
|
|
|
|
return self;
|
|
|
|
}
|
|
|
|
|
2015-08-24 10:14:33 +00:00
|
|
|
RCT_NOT_IMPLEMENTED(- (instancetype)initWithCoder:(NSCoder *)aDecoder)
|
2015-06-15 14:53:45 +00:00
|
|
|
|
2015-03-14 08:22:25 +00:00
|
|
|
- (void)goForward
|
|
|
|
{
|
|
|
|
[_webView goForward];
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)goBack
|
|
|
|
{
|
|
|
|
[_webView goBack];
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)reload
|
|
|
|
{
|
2016-04-09 00:16:33 +00:00
|
|
|
NSURLRequest *request = [RCTConvert NSURLRequest:self.source];
|
|
|
|
if (request.URL && !_webView.request.URL.absoluteString.length) {
|
|
|
|
[_webView loadRequest:request];
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
[_webView reload];
|
|
|
|
}
|
2015-03-14 08:22:25 +00:00
|
|
|
}
|
|
|
|
|
Implemented stopLoading
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
2016-04-22 15:14:53 +00:00
|
|
|
- (void)stopLoading
|
|
|
|
{
|
|
|
|
[_webView stopLoading];
|
|
|
|
}
|
|
|
|
|
2016-10-16 13:29:14 +00:00
|
|
|
- (void)postMessage:(NSString *)message
|
|
|
|
{
|
|
|
|
NSDictionary *eventInitDict = @{
|
|
|
|
@"data": message,
|
|
|
|
};
|
|
|
|
NSString *source = [NSString
|
|
|
|
stringWithFormat:@"document.dispatchEvent(new MessageEvent('message', %@));",
|
|
|
|
RCTJSONStringify(eventInitDict, NULL)
|
|
|
|
];
|
|
|
|
[_webView stringByEvaluatingJavaScriptFromString:source];
|
|
|
|
}
|
|
|
|
|
2017-01-07 04:13:20 +00:00
|
|
|
- (void)injectJavaScript:(NSString *)script
|
|
|
|
{
|
|
|
|
[_webView stringByEvaluatingJavaScriptFromString:script];
|
|
|
|
}
|
|
|
|
|
2016-02-02 02:00:18 +00:00
|
|
|
- (void)setSource:(NSDictionary *)source
|
2015-06-15 14:53:45 +00:00
|
|
|
{
|
2016-02-02 02:00:18 +00:00
|
|
|
if (![_source isEqualToDictionary:source]) {
|
|
|
|
_source = [source copy];
|
|
|
|
|
|
|
|
// Check for a static html source first
|
|
|
|
NSString *html = [RCTConvert NSString:source[@"html"]];
|
|
|
|
if (html) {
|
|
|
|
NSURL *baseURL = [RCTConvert NSURL:source[@"baseUrl"]];
|
2016-02-19 14:43:36 +00:00
|
|
|
if (!baseURL) {
|
|
|
|
baseURL = [NSURL URLWithString:@"about:blank"];
|
|
|
|
}
|
2016-02-02 02:00:18 +00:00
|
|
|
[_webView loadHTMLString:html baseURL:baseURL];
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
NSURLRequest *request = [RCTConvert NSURLRequest:source];
|
|
|
|
// Because of the way React works, as pages redirect, we actually end up
|
|
|
|
// passing the redirect urls back here, so we ignore them if trying to load
|
|
|
|
// the same url. We'll expose a call to 'reload' to allow a user to load
|
|
|
|
// the existing page.
|
|
|
|
if ([request.URL isEqual:_webView.request.URL]) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (!request.URL) {
|
|
|
|
// Clear the webview
|
|
|
|
[_webView loadHTMLString:@"" baseURL:nil];
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
[_webView loadRequest:request];
|
2015-03-14 08:22:25 +00:00
|
|
|
}
|
2015-03-31 17:05:59 +00:00
|
|
|
}
|
|
|
|
|
2015-03-14 08:22:25 +00:00
|
|
|
- (void)layoutSubviews
|
|
|
|
{
|
|
|
|
[super layoutSubviews];
|
|
|
|
_webView.frame = self.bounds;
|
|
|
|
}
|
|
|
|
|
|
|
|
- (void)setContentInset:(UIEdgeInsets)contentInset
|
|
|
|
{
|
|
|
|
_contentInset = contentInset;
|
|
|
|
[RCTView autoAdjustInsetsForView:self
|
|
|
|
withScrollView:_webView.scrollView
|
|
|
|
updateOffset:NO];
|
|
|
|
}
|
|
|
|
|
2016-02-26 16:19:40 +00:00
|
|
|
- (void)setScalesPageToFit:(BOOL)scalesPageToFit
|
|
|
|
{
|
|
|
|
if (_webView.scalesPageToFit != scalesPageToFit) {
|
|
|
|
_webView.scalesPageToFit = scalesPageToFit;
|
|
|
|
[_webView reload];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
- (BOOL)scalesPageToFit
|
|
|
|
{
|
|
|
|
return _webView.scalesPageToFit;
|
|
|
|
}
|
|
|
|
|
2015-04-21 01:01:46 +00:00
|
|
|
- (void)setBackgroundColor:(UIColor *)backgroundColor
|
|
|
|
{
|
|
|
|
CGFloat alpha = CGColorGetAlpha(backgroundColor.CGColor);
|
|
|
|
self.opaque = _webView.opaque = (alpha == 1.0);
|
|
|
|
_webView.backgroundColor = backgroundColor;
|
|
|
|
}
|
|
|
|
|
|
|
|
- (UIColor *)backgroundColor
|
|
|
|
{
|
|
|
|
return _webView.backgroundColor;
|
|
|
|
}
|
|
|
|
|
2015-11-14 18:25:00 +00:00
|
|
|
- (NSMutableDictionary<NSString *, id> *)baseEvent
|
2015-03-14 08:22:25 +00:00
|
|
|
{
|
2015-11-14 18:25:00 +00:00
|
|
|
NSMutableDictionary<NSString *, id> *event = [[NSMutableDictionary alloc] initWithDictionary:@{
|
Added mechanism for directly mapping JS event handlers to blocks
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).
2015-09-02 12:58:10 +00:00
|
|
|
@"url": _webView.request.URL.absoluteString ?: @"",
|
2015-03-14 08:22:25 +00:00
|
|
|
@"loading" : @(_webView.loading),
|
Added mechanism for directly mapping JS event handlers to blocks
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).
2015-09-02 12:58:10 +00:00
|
|
|
@"title": [_webView stringByEvaluatingJavaScriptFromString:@"document.title"],
|
2015-08-24 10:14:33 +00:00
|
|
|
@"canGoBack": @(_webView.canGoBack),
|
|
|
|
@"canGoForward" : @(_webView.canGoForward),
|
2015-03-14 08:22:25 +00:00
|
|
|
}];
|
|
|
|
|
|
|
|
return event;
|
|
|
|
}
|
|
|
|
|
2015-09-04 12:50:01 +00:00
|
|
|
- (void)refreshContentInset
|
|
|
|
{
|
|
|
|
[RCTView autoAdjustInsetsForView:self
|
|
|
|
withScrollView:_webView.scrollView
|
|
|
|
updateOffset:YES];
|
|
|
|
}
|
|
|
|
|
2015-03-14 08:22:25 +00:00
|
|
|
#pragma mark - UIWebViewDelegate methods
|
|
|
|
|
2015-06-15 14:53:45 +00:00
|
|
|
- (BOOL)webView:(__unused UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request
|
2015-03-14 08:22:25 +00:00
|
|
|
navigationType:(UIWebViewNavigationType)navigationType
|
|
|
|
{
|
2015-11-04 16:42:28 +00:00
|
|
|
BOOL isJSNavigation = [request.URL.scheme isEqualToString:RCTJSNavigationScheme];
|
|
|
|
|
2016-03-10 18:20:53 +00:00
|
|
|
static NSDictionary<NSNumber *, NSString *> *navigationTypes;
|
|
|
|
static dispatch_once_t onceToken;
|
|
|
|
dispatch_once(&onceToken, ^{
|
|
|
|
navigationTypes = @{
|
|
|
|
@(UIWebViewNavigationTypeLinkClicked): @"click",
|
|
|
|
@(UIWebViewNavigationTypeFormSubmitted): @"formsubmit",
|
|
|
|
@(UIWebViewNavigationTypeBackForward): @"backforward",
|
|
|
|
@(UIWebViewNavigationTypeReload): @"reload",
|
|
|
|
@(UIWebViewNavigationTypeFormResubmitted): @"formresubmit",
|
|
|
|
@(UIWebViewNavigationTypeOther): @"other",
|
|
|
|
};
|
|
|
|
});
|
|
|
|
|
2015-11-04 16:42:28 +00:00
|
|
|
// skip this for the JS Navigation handler
|
|
|
|
if (!isJSNavigation && _onShouldStartLoadWithRequest) {
|
2015-11-14 18:25:00 +00:00
|
|
|
NSMutableDictionary<NSString *, id> *event = [self baseEvent];
|
2015-11-04 16:42:28 +00:00
|
|
|
[event addEntriesFromDictionary: @{
|
|
|
|
@"url": (request.URL).absoluteString,
|
2016-03-10 18:20:53 +00:00
|
|
|
@"navigationType": navigationTypes[@(navigationType)]
|
2015-11-04 16:42:28 +00:00
|
|
|
}];
|
|
|
|
if (![self.delegate webView:self
|
|
|
|
shouldStartLoadForRequest:event
|
|
|
|
withCallback:_onShouldStartLoadWithRequest]) {
|
|
|
|
return NO;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Added mechanism for directly mapping JS event handlers to blocks
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).
2015-09-02 12:58:10 +00:00
|
|
|
if (_onLoadingStart) {
|
|
|
|
// We have this check to filter out iframe requests and whatnot
|
|
|
|
BOOL isTopFrame = [request.URL isEqual:request.mainDocumentURL];
|
|
|
|
if (isTopFrame) {
|
2015-11-14 18:25:00 +00:00
|
|
|
NSMutableDictionary<NSString *, id> *event = [self baseEvent];
|
Added mechanism for directly mapping JS event handlers to blocks
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).
2015-09-02 12:58:10 +00:00
|
|
|
[event addEntriesFromDictionary: @{
|
|
|
|
@"url": (request.URL).absoluteString,
|
2016-03-10 18:20:53 +00:00
|
|
|
@"navigationType": navigationTypes[@(navigationType)]
|
Added mechanism for directly mapping JS event handlers to blocks
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).
2015-09-02 12:58:10 +00:00
|
|
|
}];
|
|
|
|
_onLoadingStart(event);
|
|
|
|
}
|
2015-03-14 08:22:25 +00:00
|
|
|
}
|
|
|
|
|
2017-07-25 11:40:19 +00:00
|
|
|
if (isJSNavigation && [request.URL.host isEqualToString:kPostMessageHost]) {
|
2016-10-16 13:29:14 +00:00
|
|
|
NSString *data = request.URL.query;
|
|
|
|
data = [data stringByReplacingOccurrencesOfString:@"+" withString:@" "];
|
|
|
|
data = [data stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
|
|
|
|
|
|
|
|
NSMutableDictionary<NSString *, id> *event = [self baseEvent];
|
|
|
|
[event addEntriesFromDictionary: @{
|
|
|
|
@"data": data,
|
|
|
|
}];
|
2017-07-28 18:32:00 +00:00
|
|
|
|
|
|
|
NSString *source = @"document.dispatchEvent(new MessageEvent('message:received'));";
|
|
|
|
|
|
|
|
[_webView stringByEvaluatingJavaScriptFromString:source];
|
|
|
|
|
2016-10-16 13:29:14 +00:00
|
|
|
_onMessage(event);
|
|
|
|
}
|
|
|
|
|
2015-07-02 01:06:39 +00:00
|
|
|
// JS Navigation handler
|
2015-11-04 16:42:28 +00:00
|
|
|
return !isJSNavigation;
|
2015-03-14 08:22:25 +00:00
|
|
|
}
|
|
|
|
|
2015-06-15 14:53:45 +00:00
|
|
|
- (void)webView:(__unused UIWebView *)webView didFailLoadWithError:(NSError *)error
|
2015-03-14 08:22:25 +00:00
|
|
|
{
|
Added mechanism for directly mapping JS event handlers to blocks
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).
2015-09-02 12:58:10 +00:00
|
|
|
if (_onLoadingError) {
|
|
|
|
if ([error.domain isEqualToString:NSURLErrorDomain] && error.code == NSURLErrorCancelled) {
|
|
|
|
// NSURLErrorCancelled is reported when a page has a redirect OR if you load
|
|
|
|
// a new URL in the WebView before the previous one came back. We can just
|
|
|
|
// ignore these since they aren't real errors.
|
|
|
|
// http://stackoverflow.com/questions/1024748/how-do-i-fix-nsurlerrordomain-error-999-in-iphone-3-0-os
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-05-31 07:08:52 +00:00
|
|
|
if ([error.domain isEqualToString:@"WebKitErrorDomain"] && error.code == 102) {
|
|
|
|
// Error code 102 "Frame load interrupted" is raised by the UIWebView if
|
|
|
|
// its delegate returns FALSE from webView:shouldStartLoadWithRequest:navigationType
|
|
|
|
// when the URL is from an http redirect. This is a common pattern when
|
|
|
|
// implementing OAuth with a WebView.
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-11-14 18:25:00 +00:00
|
|
|
NSMutableDictionary<NSString *, id> *event = [self baseEvent];
|
2015-11-04 16:42:28 +00:00
|
|
|
[event addEntriesFromDictionary:@{
|
Added mechanism for directly mapping JS event handlers to blocks
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).
2015-09-02 12:58:10 +00:00
|
|
|
@"domain": error.domain,
|
|
|
|
@"code": @(error.code),
|
|
|
|
@"description": error.localizedDescription,
|
|
|
|
}];
|
|
|
|
_onLoadingError(event);
|
|
|
|
}
|
2015-03-14 08:22:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
- (void)webViewDidFinishLoad:(UIWebView *)webView
|
|
|
|
{
|
2016-10-16 13:29:14 +00:00
|
|
|
if (_messagingEnabled) {
|
|
|
|
#if RCT_DEV
|
|
|
|
// See isNative in lodash
|
|
|
|
NSString *testPostMessageNative = @"String(window.postMessage) === String(Object.hasOwnProperty).replace('hasOwnProperty', 'postMessage')";
|
|
|
|
BOOL postMessageIsNative = [
|
|
|
|
[webView stringByEvaluatingJavaScriptFromString:testPostMessageNative]
|
|
|
|
isEqualToString:@"true"
|
|
|
|
];
|
|
|
|
if (!postMessageIsNative) {
|
|
|
|
RCTLogError(@"Setting onMessage on a WebView overrides existing values of window.postMessage, but a previous value was defined");
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
NSString *source = [NSString stringWithFormat:
|
2017-07-28 18:32:00 +00:00
|
|
|
@"(function() {"
|
|
|
|
"window.originalPostMessage = window.postMessage;"
|
|
|
|
|
|
|
|
"var messageQueue = [];"
|
|
|
|
"var messagePending = false;"
|
|
|
|
|
|
|
|
"function processQueue() {"
|
|
|
|
"if (!messageQueue.length || messagePending) return;"
|
|
|
|
"messagePending = true;"
|
|
|
|
"window.location = '%@://%@?' + encodeURIComponent(messageQueue.shift());"
|
|
|
|
"}"
|
|
|
|
|
|
|
|
"window.postMessage = function(data) {"
|
|
|
|
"messageQueue.push(String(data));"
|
|
|
|
"processQueue();"
|
|
|
|
"};"
|
|
|
|
|
|
|
|
"document.addEventListener('message:received', function(e) {"
|
|
|
|
"messagePending = false;"
|
|
|
|
"processQueue();"
|
|
|
|
"});"
|
|
|
|
"})();", RCTJSNavigationScheme, kPostMessageHost
|
2016-10-16 13:29:14 +00:00
|
|
|
];
|
|
|
|
[webView stringByEvaluatingJavaScriptFromString:source];
|
|
|
|
}
|
2015-07-08 00:07:52 +00:00
|
|
|
if (_injectedJavaScript != nil) {
|
Send the evaluation of the injectedJavaScript prop back to the React Native side
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
2015-10-24 03:22:40 +00:00
|
|
|
NSString *jsEvaluationValue = [webView stringByEvaluatingJavaScriptFromString:_injectedJavaScript];
|
2015-11-04 16:42:28 +00:00
|
|
|
|
2015-11-14 18:25:00 +00:00
|
|
|
NSMutableDictionary<NSString *, id> *event = [self baseEvent];
|
2015-11-04 16:42:28 +00:00
|
|
|
event[@"jsEvaluationValue"] = jsEvaluationValue;
|
|
|
|
|
Send the evaluation of the injectedJavaScript prop back to the React Native side
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
2015-10-24 03:22:40 +00:00
|
|
|
_onLoadingFinish(event);
|
2015-03-14 08:22:25 +00:00
|
|
|
}
|
|
|
|
// we only need the final 'finishLoad' call so only fire the event when we're actually done loading.
|
Send the evaluation of the injectedJavaScript prop back to the React Native side
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
2015-10-24 03:22:40 +00:00
|
|
|
else if (_onLoadingFinish && !webView.loading && ![webView.request.URL.absoluteString isEqualToString:@"about:blank"]) {
|
Added mechanism for directly mapping JS event handlers to blocks
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).
2015-09-02 12:58:10 +00:00
|
|
|
_onLoadingFinish([self baseEvent]);
|
2015-03-14 08:22:25 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
@end
|