Summary:
This PR removes TextLayoutBuilder, which is not used anywhere.
Pull Request resolved: https://github.com/facebook/react-native/pull/20600
Reviewed By: achen1
Differential Revision: D9367345
Pulled By: hramos
fbshipit-source-id: 407a6a80f5c69650fcc7167b28214f7315beed2f
Summary:
This PR removes infer-annotation from the repo and uses latest version of it from maven.
Pull Request resolved: https://github.com/facebook/react-native/pull/20599
Differential Revision: D9437594
Pulled By: hramos
fbshipit-source-id: 93c33041dd8a61b220c352fb187a23bb2dd1b4db
Summary:
Fixes#20769
Release notes
--------------
[CLI] [BUGFIX] [local-cli/server/checkNodeVersion.js] - Disable auto-formatting in `local-cli/server/checkNodeVersion.js` since it introduces ES6 and ES7 syntax (trailing comma in argument list) which in turn makes ES5 engines crash with a `SyntaxError`.
Pull Request resolved: https://github.com/facebook/react-native/pull/20779
Differential Revision: D9468346
Pulled By: hramos
fbshipit-source-id: 24761a377a5fd104e11ed6b6e86da15e96a0e38b
Summary:
@public
This diff fixes the `projectRoot` calculation on React Native when the app does not have a config file. This should fix the issues reported in https://github.com/facebook/react-native/issues/20712
Reviewed By: hramos
Differential Revision: D9444982
fbshipit-source-id: 4cb41fa5224d2addf92976cc119e49dea6a6346b
Summary:
We have several disabled tests in Circle, and they are not running at all.
This prevents us from seeing when a disabled test might actually be fixed, as enabling the test requires uncommenting the correct line in Circle CI's config.
In this PR, we use the existing swallow_error script to run known-failing steps, without failing the job. This will let us see the step's output in CI, without polluting PRs that have not introduced new failures to CI.
Pull Request resolved: https://github.com/facebook/react-native/pull/20775
Differential Revision: D9442412
Pulled By: hramos
fbshipit-source-id: 83c930811a559fdcf6d7b926b4073343e862d2b3
Summary:
Commit 79e498b7fb claims that "--terminal" has been added as an argument to the "run-android" script which it hasn't. Instead it adds a new environment variable "process.env.REACT_TERMINAL" which seems to be undocumented and nowhere else in the repository.
This commit now allows Linux and OSX users to specify their custom terminal :
react-native run-android --terminal=x-terminal-emulator
Additionally the metro bundler child process "detached" option has been set to false if no terminal has been specified on Linux which fixes an issue where the packager would be running in the background and would have to manually be closed by finding the process.
Fixes#18122
Pull Request resolved: https://github.com/facebook/react-native/pull/20584
Differential Revision: D9234990
Pulled By: hramos
fbshipit-source-id: 60e4cc57b2790c419d5a4f9027add04313ddf6f8
Summary:
Per [this comment on the issue](https://github.com/facebook/react-native/issues/20710#issuecomment-414631827):
> Babel by default tries to find .babelrc files to configure itself, and once it finds the one from the RN app (which links to the RN preset that only works on Babel 7) it fails.
> The easiest patch to fix this issue is to add babelrc: false to the babel-register method, so Babel does not read any additional .babelrc file.
Fixes#20710
Pull Request resolved: https://github.com/facebook/react-native/pull/20790
Differential Revision: D9458502
Pulled By: hramos
fbshipit-source-id: 3a0ed7261322fdd9e0c0840f8a3944974f38b233
Summary:
@public
We can't dynamically link `WebKit` because doing so will impact cold start of all our Apps.
This diff includes a few changes:
1. Weakly link the `WebKit` framework in the `ReactInternal` library, so that the compiler doesn't die when it encounters a WebKit symbol.
2. Undo dynamic linking of WebKit in Catalyst.
3. Undo dynamic linking of WebKit in AdsManager
4. Before the first `WKWebView` is instantiated, dynamically load the `WebKit` framework.
The end result of these changes is that WebKit will be loaded only when it's going to be used.
Reviewed By: mmmulani
Differential Revision: D6564328
fbshipit-source-id: a45a44e774d0c61c1fb578a6fa3d16bb08f68ac9
Summary:
@public
The `WKWebView` class doesn't expose a `scalesPageToFit` property, unlike `UIWebView`. Therefore, the `scalesPageToFit` RN prop is be a bit tricky to implement with `WKWebView`.
For the time being, this diff adds warnings to `<WebView/>` whenever `useWebKit={true}` and `scalesPageToFit` is set. I've also updated the documentation to reflect that we don't support `scalesPageToFit` prop with the new implementation of `<WebView/>`.
Reviewed By: shergin
Differential Revision: D6429271
fbshipit-source-id: adf858cb67ba221c70d6d6f1bd6cff505e90c365
Summary:
@public
This diff adds the `useWebKit` property to the `<WebView/>` React Native component. On iOS, when this property is true, we use `RCTWKWebView`. Otherwise, we use `RCTWebView`. On Android, this property does nothing.
Reviewed By: shergin
Differential Revision: D6423374
fbshipit-source-id: 006bfaaf12984fac0174c0b5bb897c009c026cd0
Summary:
@public
This diff introduces two new props:
1. **automaticallyAdjustContentInsets**: Controls whether to adjust the content inset for web views that are placed behind a navigation bar, tab bar, or toolbar. The default value is true.
1. **contentInset**: The amount by which the web view content is inset from the edges of the scroll view. Defaults to {top: 0, left: 0, bottom: 0, right: 0}.
**Note:** There're some inconsistencies between how `UIWebView` and `WKWebView` render web pages with respect to the `contentInset` property. These two videos illustrate the problem:
**UIWebView**
[[ P58674349 | Playground.js ]]
https://pxl.cl/9R9V
**WKWebView**
[[ P58674348 | Playground.js ]]
https://pxl.cl/9R9W
Here's a stack overflow answer describing the problem: https://stackoverflow.com/a/35472603.
Reviewed By: shergin
Differential Revision: D6432181
fbshipit-source-id: aee6dac65d28435381ebec90519474b4707c7bab
Summary:
@public
This diff implements background colors for the `RCTWKWebView` component by proxying the background color prop to the underlying `WKWebView` and its underlying `UIScrollView`.
There's few differences between `backgroundColor` in `RCTWebView` and `RCTWKWebView` implementations:
1. With `UIWebView,` the background color gets applied after the page loads. With `WKWebView`, this isn't necessarily true. This results in a white flicker on solid backgrounds because sometimes, the background color is set before the page loads. This video illustrates the problem: https://our.intern.facebook.com/intern/px/p/9QBH
1. As far as I can tell, `WKWebView` doesn't handle transparent backgrounds correctly. Either that, or I could be setting the background color incorrectly. I set the background color to `rgba(1, 1, 1, 0.5)` and recorded how both `RCTWebView` and `RCTWKWebView` render. These two videos indicate the differences:
**RCTWebView: Lighter background**
https://pxl.cl/9R13
**RCTWKWebView: Darker background**
https://pxl.cl/9R1b
I tried to replicate this on the web. According to [[ https://our.intern.facebook.com/intern/fiddle/zCHu/ | this fiddle ]], `RCTWebView` is correct. Clearly, RCTWKWebView is rendering transparent backgrounds a bit darker than necessary. This doesn't seem simple to debug, so I've created a task to document this work: T23815343. I'll get to it eventually.
Reviewed By: shergin
Differential Revision: D6398209
fbshipit-source-id: 1812cb68133bc18a3278f6b328d7b085362528b0
Summary:
When text is rendered in `WKWebView` WebKit component, the component itself can detect things like phone numbers, flight numbers, links, etc. and render them with additional functionality.
For example, when the text `apple.com` is detected, if the `link` data detector type is enabled, the web view will actually render a link that takes the user to the Apple home page.
In this diff, I implement the `dataDetectorTypes` prop. The data detector types supported are:
1. phoneNumber
1. link
1. address
1. calendarEvent
1. trackingNumber
1. flightNumber
1. lookupSuggestion
These enums are documented in the [[ https://developer.apple.com/documentation/webkit/wkdatadetectortypes | WKDataDetectorTypes docs ]].
Reviewed By: shergin
Differential Revision: D6392546
fbshipit-source-id: 4dd373f0ac52f898163cd959eeef6672e55b42a6
Summary:
HTML video elements can have the `autoplay` attribute, which forces them to play automatically whenever they load on the page.
In this diff, I introduce a new prop `mediaPlaybackRequiresUserAction`, which allows us to control whether video or audio element autoplays even when `autoplay` is set.
Reviewed By: shergin
Differential Revision: D6382256
fbshipit-source-id: 617508653910d600bc43f7f68c6dfd17ab1b6dd8
Summary:
For iPhones with small screen sizes (e.g: iPhone 5s), inside the `<WKWebView/>` component, videos will play in fullscreen mode. In this diff, I introduce a prop called `allowsInlineMediaPlayback` that when set to true, will allow videos to play inline.
**Note:** For videos to play inline, the HTML video element must also have a `playsinline` attribute on it.
Reviewed By: shergin
Differential Revision: D6379770
fbshipit-source-id: a0130720ffede6c24a90cad0c97a75b657d77017
Summary:
@public
This diff introduces the native backend for a new WKWebView prop: `onShouldStartLoadWithRequest`.
In the final component, the behaviour will be as follows: Whenever the user navigates around in the web view, we call `onShouldStartLoadWithRequest` with the navigation event. If `onShouldStartLoadWithRequest` returns `true`, we continue the navigation. Otherwise, we abort it.
Reviewed By: shergin
Differential Revision: D6370317
fbshipit-source-id: e3cdd7e2a755125aebdb6df67e7b39116228bdfb
Summary:
@public
This diff implements the `reload` and `stopLoading` methods for `WKWebView`. Their functionality is self-explanatory.
Reviewed By: shergin
Differential Revision: D6369292
fbshipit-source-id: ba176f4406e0a67606406f36dd66f7615f4796c3
Summary:
@public
This diff implements the `goForward` and `goBack` methods on `WKWebView`.
1. `goForward` moves the web view one screen forward in the browser history.
1. `goBack` moves the web view one screen back in the browser history.
Reviewed By: shergin
Differential Revision: D6367495
fbshipit-source-id: e100ca00e92a6eaa30d2af1af642ba79a9c9feae
Summary:
@public
This diff introduces a method called `injectJavaScript(script)` on the React Native `<WKWebView/>` component. When called with a string, it evaluates that string as JavaScript within the web view.
Reviewed By: shergin
Differential Revision: D6367445
fbshipit-source-id: f68afeff42535dc991747f96a63f3c956faf13d3
Summary:
@public
The content that renders within the `WKWebView` instance actually renders inside a `UIScrollView`. On that scroll view, we can adjust the `decelerationRate`, which controls how fast the view stops scrolling after the user lets go while scrolling.
In this diff, I implemented the `decelerationRate` prop for `WKWebView`, which gets forwarded to the `UIScrollView` instance underlying the web view.
**Note:** Even though we accept a floating point value for the deceleration rate, the native `UIScrollView` component only allows two inputs:
1. `UIScrollViewDecelerationRateNormal`: 0.998
2. `UIScrollViewDecelerationRateFast`: 0.99
As far as I know, it seems to just round up to the nearest valid `CGFloat` (or down if number > 0.998), for any invalid numbers.
Reviewed By: mmmulani
Differential Revision: D6307262
fbshipit-source-id: 98c4395702415aa36519f9e9bd84f043be3a5881
Summary:
@public
The content of `WKWebView` renders within a scrollview. In this diff, I'm introducing the prop `scrollEnabled` to allow developers to control whether scrolling is enabled within the scroll view, or not.
Reviewed By: mmmulani
Differential Revision: D6307001
fbshipit-source-id: 5a199c6c3b8535e45a5a3cb6041e822bb7af2362
Summary:
@public
The content that loads inside `WKWebView` renders within a `ScrollView`. Suppose the user pulls the page down when its top edge hits the top edge of the web view. Then, one of two things can happen as the user continues to pull the page down:
1. We let the page be pulled past the top edge of the web view.
1. We fix the page's vertical offset to 0 so that it doesn't move past the top edge of the web view.
The property that controls this behaviour is `<WKWebView bounces={true|false}/>`. In this diff, I implement it.
Reviewed By: mmmulani
Differential Revision: D6306866
fbshipit-source-id: 7763df78676215c3dd0bd7a029497a6eca1873ab
Summary:
@public
This diff implements message passing between the `WKWebView` and React Native. As with `<WebView/>`, we can only send/receive strings.
**Usage:**
1. Set `messagingEnabled` to `true`.
1. To send data from the web view to React Native, call `postMessage(data)` within the web view. This forces React Native to execute the `onMessage` prop on the `WKWebView` component. `onMessage` will be called with an event `e`, where `e.nativeEvent.data` will be the data you passed into `postMessage`.
1. To send data from React Native to the web view, call `UIManager.dispatchViewManagerCommand` to dispatch the `UIManager.RCTWKWebView.Commands.postMessage` command. Look at [[ https://fburl.com/u1wusf2f | this part of the existing `<WebView/>` ]] component for more details. After you make the call, React Native will dispatch a `'message'` event to the `document` object within the webview. You can listen to the event by doing `document.addEventListener('message', callback)`. Let the event dispatched be `e`. Then, `e.data` is the data you sent over from React Native.
[[ P58627181 | This Playground.js ]] illustrates the usage.
Reviewed By: shergin
Differential Revision: D6304850
fbshipit-source-id: 29075ef753296e9fb5a9cddeb1ad0f4ff7e28650
Summary:
@public
This diff includes four very straightforward changes:
1. Whenever the WebView starts loading, the `onLoadingStart` hook should be executed. The event passed into this hook should be decorated with the `navigationType`.
1. Whenever the WebView errors out while loading, the `onLoadingError` hook should be executed.
1. Whenever the WebView finishes loading (without any errors), the `onLoadingFinish` hook should be executed.
1. The serialized JavaScript passed into the `injectedJavaScript` prop should be executed when the WebView finishes loading. After execution finishes, the `onLoadingFinish` prop should be called with the serialized completion value of this JavaScript.
Reviewed By: shergin
Differential Revision: D6293532
fbshipit-source-id: 21407c766f73413046823ae605afc21e85cf9db6
Summary:
@public
`UIWebView` has been deprecated and replaced by `WKWebView`. This diff introduces a new component `WKWebView` that simply renders a `WKWebView` on iOS.
This is the first in the stack of many diffs that'll be required to fully replace `UIWebView` with `WKWebView` in the `<WebView/>` React Native component. Eventually, I hope to introduce a prop called `useWebKitImplementation`, which, when true, will force RN to use `WKWebView` instead of `UIWebView` for the `<WebView/>` component.
The only thing that's been implemented so far is the `source` property.
Reviewed By: mmmulani
Differential Revision: D6266100
fbshipit-source-id: 65862e34bd98db7fff0349cf26888afee43a56e4
Summary:
The `--reset-cache` argument was not working correctly with the `bundle` command. This ensures the `--reset-cache` arg is passed to metro.
Fixes#20703
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
Pull Request resolved: https://github.com/facebook/react-native/pull/20706
Differential Revision: D9400548
Pulled By: hramos
fbshipit-source-id: 2c7ed0226cfcdffa8cc77506500c314552baef3f
Summary:
add `packager.sh` for run-android task for unix like system. This only fix on linux and macOS.
pass all current ci.
none
[GENERAL] [BUGFIX] [CLI] - add `packager.sh` back for run-android task
Pull Request resolved: https://github.com/facebook/react-native/pull/20751
Differential Revision: D9398197
Pulled By: hramos
fbshipit-source-id: 213b066c0c034136c5ad5bbf8d45c6f331b1d185
Summary:
React Native overrides the `metro.config.js` settings for, e.g., `hasteImplModulePath`, which prevents us from adding a `metro.config.js` file to the repo for `react-native-windows` to allow us to resolve Haste modules at the top-level of the repo. This change ensures that if a user has a `metro.config.js` file, those settings are not overwritten by React Native.
Pull Request resolved: https://github.com/facebook/react-native/pull/20705
Differential Revision: D9390146
Pulled By: hramos
fbshipit-source-id: 5ccc137490410ace72d7b0e68f2bafcbb233c59f
Summary: New version of metro to add module.id
Reviewed By: rafeca
Differential Revision: D9360070
fbshipit-source-id: fc0e2d98483404ddbc1ca920c4f42f52573734c6
Summary: Adds missing comma, following up on https://github.com/facebook/react-native/pull/20178. Thanks to LinusU for pointing out the error.
Reviewed By: TheSavior
Differential Revision: D9242887
fbshipit-source-id: 4b547396722d0e37dc5c8eb3439b9a441c3c0ac2
Summary: Fixes the `Touchable` debug view. The `child.type` is no longer a subclass of `React.Component` and no longer has `displayName`. It should be fine to have a hard dependency on `Text` and `View`, because... what app does not use them?
Reviewed By: TheSavior
Differential Revision: D9232036
fbshipit-source-id: 06f4091bf8e21cada3af50def2fdd41a6ad84f79
Summary:
@public
I'm surprised this hasn't caused an issue earlier.
RCTTouchHandler is hooked up to RCTSurfaceView which itself contains a rootView. Thus when this calculation happens, a root view is never found.
We can't assign to the root view since it created and destroyed frequently, so it makes the most sense to look for the RCTSurfaceView here and treat it as a root view.
Reviewed By: fkgozali
Differential Revision: D9296840
fbshipit-source-id: ba5320583201f9d5c0176847cc6e6087b6a6459b
Summary:
.android.js files may be checked (when the next version of flow is released) by using `flow start --flowconfig-name .flowconfig.android` and `flow status --flowconfig-name .flowconfig.android`
This diff adds suppressions to the errors that are in .android.js files, which flow does not check right now.
When site is `react_native_fb` or `react_native_android_fb`, error will be suppressed when checking with .flowconfig.android
When site is `react_native_fb` or `react_native_ios_fb`, error will be suppressed when checking with .flowconfig.
You can use `react_native_fb` when it should be suppressed for both.
The controller you requested could not be found.
Reviewed By: TheSavior
Differential Revision: D9122178
fbshipit-source-id: 0ec9d3cae3d887f58645e6585b2a3f6c3889b13e
Summary:
This PR fixes an issue I have found while playing with native animated driver nodes.
I discovered the bug when using animated views that have both animated props and styles. See this snack to see an example: https://snack.expo.io/B17SFXy8Q
In that example we set `opacity` and `style` props which both contain animated props. This is not an usual way to do that, as normally you would place `opacity` inside the `styles` in which case the bug won't surface. But this is only done for demo purposes and in practice the problem will occur if you have a custom native view that exposes props that are not styles and can be animated.
In the above example you get this error:
> Invariant Violation: Attempt to get native tag from node not marked as "native"
When `opacity` is moved into `styles` container the problem no longer occurs.
The problem turned out to be related to the initialization code responsible for creating native animated nodes. In all subclasses of `AnimatedWithChildren` (like `AimatedAddition`) we only call `super.__makeNative` after we call `__makeNative` method on the child nodes. This order was reversed in `AnimatedStyle` and `AnimatedTransform`. As a result when `super.__makeNative` is called in `AnimatedStyle`, we try to call `__getNativeTag` on children nodes not yet marked as native which results in the error described above ("Attempt to get native tag...").
We should instead follow the order of calling `super.__makeNative` that is used in the remaining subclasses of `AnimatedWithChildren`. Such that all the children nodes are first converted to native prior to calling superclass method. This is what this PR is changing.
Pull Request resolved: https://github.com/facebook/react-native/pull/20658
Differential Revision: D9297191
Pulled By: hramos
fbshipit-source-id: f5e394fb259ff514c7c1433edcb5fc89203f55e2
Summary:
@public
This diff fixes two bugs:
1. When you load a `<WebView/>` with an HTML source string, HTML source doesn't render in the `<WebView/>`. Instead, we get this warning: https://pxl.cl/grz3. Here's what the above page should look like when correctly rendered: https://pxl.cl/grzt
2. Furthermore, you render a blank `<WebView/>` (i.e: with no source prop), it should display a blank page. Instead, we get this warning: https://pxl.cl/grz3
**Bugfix:**
One solution I found was to ensure that `about:blank` is always whitelisted. That way, we don't ever abort navigations to blank pages, which occur when we do:
```ObjectiveC
/** Line 134 in RCTWebView.m */
[_webView loadHTMLString:@"" baseURL:nil];
```
and
```ObjectiveC
/** Line 115 in RCTWebView.m */
if (html) {
NSURL *baseURL = [RCTConvert NSURL:source[@"baseUrl"]];
if (!baseURL) {
baseURL = [NSURL URLWithString:@"about:blank"];
}
[_webView loadHTMLString:html baseURL:baseURL];
return;
}
```
Reviewed By: yungsters, mmmulani
Differential Revision: D9259852
fbshipit-source-id: e1b9673fcd8c3d0df77308df8c4a632a2b596bfb
