Summary:
This diff implements a new model of managing `enabled` flag in EventEmitter.
Now we simply rely on `eventTarget_` is not being `nullptr` (and we reset the pointer to "disable" the event emitter).
Reviewed By: mdvacca
Differential Revision: D9764857
fbshipit-source-id: 1dd3ce0c8589048babbf2dbac9f8359358b31a34
Summary:
As we did in the previous diff, here we implemented `EventEmitter`'s ownership model as a `shared_ptr`. This change fixes problem with leaking `WeakObject`s which happens on hot-reload.
So, in short:
* `EventTargetWrapper` object owns `jsi::WeakObject` that can be converted to actual `jsi::Object` that represent event target in JavaScript realm;
* `EventTargetWrapper` and `jsi::WeakObject` objects must be deallocated as soon as native part does not need them anymore;
* `EventEmitter` objects retain `EventTarget` objects;
* `EventEmitter` can loose event target object in case if assosiated `ShadowNode` got unmounted (not deallocated); in this case `EventEmitter` is loosing possibility to dispatch event even if some mounting-layer code is still retaining it.
Reviewed By: mdvacca
Differential Revision: D9762755
fbshipit-source-id: 96e989767a32914db9f4627fce51b044c71f257a
Summary:
Previously, we used special JSI bindings method to release an event handler (`JSIReleaseFabricEventHandler`). Now we expose this ownership model as a regular `std::shared_ptr`, so when the owner got deallocated, the event handler will be released automatically.
Why not use `unique_ptr`? `unique_ptr` is faster (and simpler) indeed, but it does not provide `type erasure` functionality that we need; to use `unique_ptr` we would have to make JSI an explicit Fabric dependency (we will probably end up with it eventually, but I this particular case is not a good reason for that).
All interactions with `eventHandler_` are done in a non-owning manner, so it's as performant as unique_ptr anyway.
(Please ignore all changes in JSCFabricUIManager.h/cpp files, we will delete them soon.)
Reviewed By: mdvacca
Differential Revision: D9756732
fbshipit-source-id: bffdee0c724dc95855ced7c35e7c13cf1554796e
Summary:
This PR tries to consolidate Android native dependencies versions to make it less error prone to version bumps.
Pull Request resolved: https://github.com/facebook/react-native/pull/20742
Differential Revision: D9818155
Pulled By: hramos
fbshipit-source-id: 9bf631640910edad5731014f4e23dbca45af2b59
Summary:
Adding the new `textContentType` options from iOS 12. `newPassword` helps the OS know to put a password field into the keychain, and `oneTimeCode` hints that the field will take input from an SMS one time code.
Pull Request resolved: https://github.com/facebook/react-native/pull/21079
Differential Revision: D9813328
Pulled By: TheSavior
fbshipit-source-id: d2c04b41121b32f185af38ea4c642924e261a043
Summary:
While these were intentionally used in the open, and never were abused, it has become a distraction whenever they are flagged.
We'll have to move this functionality to a service outside of Circle CI, as we cannot securely pass secrets to forks and PRs in Circle CI. By necessity, these PR analysis scripts must run alongside PRs.
The The controller you requested could not be found. token has already been revoked. The The controller you requested could not be found. token is not under our control, and is still valid as of this writing. The eslint token has public_repo scope, with no access to any private repos. It's no different than having a random account commenting on any public repo.
Unfortunately, revoking the The controller you requested could not be found. token affects React's use of this bot account as well.
---
Q: What does the React team need this token for?
A: It's used to analyze how a PR will impact the build size for React.
Q: What does the React Native team need this token for?
A: We do lightweight automated PR code reviews with it (eslint, flagging large PRs, etc)
Q: What can someone do with the access token?
A: The token was for the The controller you requested could not be found. GitHub account. The account has no privileged access to any organization, so in effect it's like having the token to a random GitHub account. The token has public_repo access scope, which allows it to interact with any public repository on GitHub. The attacker can leave comments on any issue, pull request, or commit, on any public open source repository on GitHub. They could spam or leave arbitrary messages. It's no different than using any random newly created GitHub account to do this, but the bot is named "React Linter", so people could have used it to make React look bad.
Q: Why didn't we just remove the token from the open source repositories? CircleCI allows you to use environment variables to keep secrets out of the repo.
A: We have configured CircleCI to hide environment variables from Circle CI jobs triggered by non-Facebook org forks and pull requests (otherwise, anyone could add a file to their fork that echoes $SUPER_SECRET and then read it from the Circle CI logs). This allows us to do things like publish to npm only on commits that actually land on the main repo, without letting random people do the same on their forks.
Q: Why can't we run these scripts on Circle CI jobs that do have access to secret environment variables?
A: It's by necessity. These scripts are meant to run on pull requests and forks. They're used to lint pull requests, after all.
Q: Why can't we run these scripts on internal Facebook infrastructure?
A: Automatic importing of arbitrary code from external sources into internal Facebook systems without a FB engineer's involvement is disallowed. We're happy to let Circle CI run unvetted code in this manner.
Q: What do other projects do in similar situations?
A: A common solution for open source projects that need to run scripts with access to GitHub without exposing the access token on CI is to use a private cloud server (i.e. a droplet in Digital Ocean, an instance on AWS...).
Q: Why don't we use the same infra used by react-native-bot to run react-linter?
A: React-Native-Bot runs once an hour or so, querying for recent issues and PRs. It does not use webhooks, and instead performs the same kind of search queries you'd use on GitHub, therefore it's not great for picking up when a PR has been updated. Circle CI is great for running scripts whenever a PR is created or updated, as Circle outages aside, we can be fairly certain a script will run any time a PR is updated. If you want to track build sizes, you really want to make sure any new commit added to a PR will trigger a re-run.
Pull Request resolved: https://github.com/facebook/react-native/pull/21058
Differential Revision: D9809842
Pulled By: hramos
fbshipit-source-id: 6ca5d2f5b48e077ec822a3aea5237534bd828850
Summary:
This PR does 2 things:
* Have Facebook internal dependencies only be added if `IS_OSS_BUILD` is `True`. This syntax is used in other BUCK files in the codebase.
* `ReactAndroid/src/androidTest/java/com/facebook/react/tests/core/BUCK`
* `ReactAndroid/src/androidTest/java/com/facebook/react/testing/rule/BUCK`
* Add a missing Android dependency to this BUCK file:
* `ReactAndroid/src/main/java/com/facebook/react/BUCK`
As a result, `test_android` is passing again.
Pull Request resolved: https://github.com/facebook/react-native/pull/21083
Differential Revision: D9809808
Pulled By: hramos
fbshipit-source-id: c840ea2892006a88fe13de1b1324746d030ebaf2
Summary:
This PR gives RNPM the ability to look for plugins in `scoped` modules.
The regexes for finding RNPM plugins will match these hypothetical examples:
* `rnpm-plugin-foo`
* `org/rnpm-plugin-foo`
The regexes for finding React Native plugins will match these hypothetical examples:
* `react-native-foo`
* `org/react-native-foo`
* `The controller you requested could not be found./module` (will be useful in the slimmening)
* `The controller you requested could not be found./module`
RNPM plugins will be able to benefit from this immediately, but React Native plugins will run into this Metro issue currently:
https://github.com/facebook/metro/issues/241
Pull Request resolved: https://github.com/facebook/react-native/pull/21082
Differential Revision: D9809094
Pulled By: hramos
fbshipit-source-id: 4b0694ad4119b37dd5664af52c48e48ebe4d7404
Summary:
NaN is not handled consistently by the bridge in all cases,
so detect it and complain. In order to make the complaint more
obvious, use JSON.stringify on the value, and a replacer so that some
of the censoring which normally takes place doesn't get in the way of
clarity.
Reviewed By: mmmulani
Differential Revision: D9779799
fbshipit-source-id: 6c1a6bfe05ecaa3aeb558acc49dfd54461e1ba74
Summary: Fixes a redbox about setting both the accessor and the value for an object. It looks like it's actually coming from PolyfillFunctions, where we set the value as well as spreading in the object descriptor for modules in DEV.
Reviewed By: yungsters
Differential Revision: D9792991
fbshipit-source-id: a2fa5d1820c5eddfd8244722771e76de62f89976
Summary:
@public
As we're doing in D9440914 (OSS 64a52532fe88b482ae4b998133d340e6e1141a0f), send text metrics in an onTextLayout callback. These can be used by surrounding views for doing complicated layout like:
- displaying a cursor at the end of text
- vertical centering using capheight-baseline
This right now isn't very performant but is only done when `onTextLayout` is set. I plan to optimize it with a capheight and xheight cache in a follow up diff.
Reviewed By: achen1
Differential Revision: D9585613
fbshipit-source-id: aa20535b8371d5aecf15822d66a0d973c9a7eeda
Summary:
To avoid "js engine: ..." appearing everywhere, only add this information
to the error message when react native is reporting errors to the server.
Reviewed By: yungsters
Differential Revision: D9754371
fbshipit-source-id: a8001480c75ccf93c953c79f26470df678871cb3
Summary:
Original commit changeset: cec3802d30b7
See my comment on original diff: D9307123
The diff regresses ImageBackground in some cases, so I'm reverting until we can re-work the diff to handle existing usages in an expected way.
Differential Revision: D9790698
fbshipit-source-id: 23ad670e004980f22bd1413eca3692f51beff717
Summary: This diff adds a new property in ReactWebView to be able to configure allowFileAccess
Reviewed By: achen1
Differential Revision: D9789466
fbshipit-source-id: 39d042ac6ef69e44f006a4c4b0c2dd900f84dbc9
Summary: In some cases, the custom implementation of this prop is undesirable, so this allows to turn it off.
Reviewed By: yungsters
Differential Revision: D9759228
fbshipit-source-id: 4f61cd900c2da9046977c11a61606a4f5f961177
Summary: When symbolication fails, allow retrying without having to reload the current JS VM.
Reviewed By: ejanzer
Differential Revision: D9760666
fbshipit-source-id: 63837c81fe77a9b0b897a858e3d64bc7dcf2c3bd
Summary: Changes YellowBox to use feather icons for the left and right navigation so that we are not dependent on the system's (sometimes funky) unicode icons.
Reviewed By: ejanzer
Differential Revision: D9759134
fbshipit-source-id: b957c24afdccc04bfe78ae4750777c387c2acef4
Summary:
The source of truth has already moved, so now we just need to fix references
This diff is mostly the result of running:
```
$ tools/mobile-unification/loadmod --fixup xplat/configurations/buck/apple/flag_defs.bzl tools/build_defs/apple/
```
Then I committed with `hg commit -I xplat/`
The controller you requested could not be found.
Differential Revision: D9772194
fbshipit-source-id: 93d23ae8e1c62440c7876cad965d963bde960db9
Summary: Back out D9614432 and partially revert D9623235 to unbreak OSS.
Reviewed By: hramos
Differential Revision: D9779548
fbshipit-source-id: 931c4987ed5acbae3790c42717662fed77599335
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary: buildifier was updated and now we sort loads!
Reviewed By: zertosh
Differential Revision: D9771824
fbshipit-source-id: 0001aa5f656d4aa40b3498d5bfd792a3d14e56e1
Summary:
Fixing error
node_modules/react-native/Libraries/NativeAnimation/RCTNativeAnimatedNodesManager.h:12:9: 'RCTAnimation/RCTValueAnimatedNode.h' file not found
I'm integrating react native into an existing app through cocoa pods and similar to other PRs
PR https://github.com/facebook/react-native/pull/16192
PR https://github.com/facebook/react-native/pull/16271
PR https://github.com/facebook/react-native/pull/17764
When integrating with cocoa pods
```
pod 'React', :path => './node_modules/react-native', :subspecs => [
'Core',
'DevSupport', # Include this to enable In-App Devmenu if RN >= 0.43
'RCTText',
'RCTNetwork',
'RCTWebSocket', # needed for debugging
'RCTImage',
'RCTWebSocket',
'BatchedBridge',
'RCTLinkingIOS',
'RCTActionSheet',
'RCTAnimation'
]
```
With `RCTAnimation` being the important part for this PR.
Also note without this PR and the other PR's above if anyone is trying to integrate react native into an existing app i.e. through cocoa pods they won't be able too. I think the latest working version is
My app wouldn't build without changing this line
PR https://github.com/facebook/react-native/pull/16192
PR https://github.com/facebook/react-native/pull/16271
PR https://github.com/facebook/react-native/pull/17764
[IOS] [BREAKING] [PODS] - Fixed RCTAnimation import for integrating with cocoapods
Pull Request resolved: https://github.com/facebook/react-native/pull/18050
Differential Revision: D9235162
Pulled By: hramos
fbshipit-source-id: 426daccf8d8952658e262d5a0e4623c72c38542c
Summary:
Instead of asking existing modules to implement `+allowJSIBinding`, introduce a temporary "empty" protocol so modules can just adopt it for migration purpose.
Eventually this protocol may just go away.
Modules need to adopt both `RCTBridgeModule` and `RCTJSINativeModule` for time being for backward compatibility.
p.s. the entire system isn't enabled yet, this is just some of the pre-reqs for NativeModule improvements.
Reviewed By: mmmulani
Differential Revision: D9762913
fbshipit-source-id: 470f640f11a5991e5cfa9c48a1931da660ebfcd2
Summary: This relied on NaN being turned into null (through JSON.stringify), which would then be handled by Yoga gracefully. But in some cases we do not call JSON.stringify and thus pass NaN directly to Yoga causing a problem.
Reviewed By: fkgozali
Differential Revision: D9764488
fbshipit-source-id: 021c9ffafba8f9bcef2476756a12df33c367bcb1
Summary:
These files support backing a `WebView` component with the WebKit-based
`WKWebView` on iOS. These files need to be included in the Xcode
build target so that they are compiled, linked and ultimately available
to the UIManager at runtime, so that the correct views can be instantiated
when a `WebView` is passed the prop `useWebKit={true}`.
Pull Request resolved: https://github.com/facebook/react-native/pull/21031
Differential Revision: D9762185
Pulled By: hramos
fbshipit-source-id: 0d699e40afd56041cbbb76d77f11ba6932403d6d
Summary:
I was watching a classic magnificent talk about modern C++ by Herb Sutter and I was totally sold on double down on using `auto` in our codebase. Surprisingly, 95% of the code base already follows Herb's guidence; I just changed the last 5% to make it consistent.
All those changes must work *exactly* like it was before.
The talk: https://youtu.be/xnqTKD8uD64?t=28m25s
Reviewed By: mdvacca
Differential Revision: D9753301
fbshipit-source-id: 9629aa485a5d6e51806cc96306c297284d4f90b8
Summary:
* Now all `RCTViewComponentView` subclasses are required to set `_props` instance variable in the constructor with a default value;
* `RCTViewComponentView`'s `_props` instance variable now has `ShadredViewProps` type (that enforced by `static_assert` in `ConcreteViewShadowNode` template);
* New we use `static_pointer_cast` instead of `dynamic_pointer_cast` for casting props.
Reviewed By: mdvacca
Differential Revision: D9734199
fbshipit-source-id: b0a0939c936f8b5b540fa5fa1e4a2f1037346fc5
Summary: This pull request removes the hard-coded version of the `metro-react-native-babel-preset` as defined in the `init` command. That way, the version always matches React Native version specified in its `package.json`, making it match Metro version.
Differential Revision: D9759540
Pulled By: hramos
fbshipit-source-id: 90835442e2db1900851cbfb8c3c625229184d851
Summary:
Upgrades `react-devtools` for React Native and Nuclide to v3.3.4.
Notably, this brings working support for the React Profiler!
Reviewed By: bvaughn
Differential Revision: D9721317
fbshipit-source-id: 898666d12a33d8b874fcb133e9353f483285edc2
Summary: ImageBackground assigned its Image the same `width` and `height` styles as itself. This became an issue for ImageBackground instances that were assigned (non 100%) percentage size values. For example, if the `width` and/or `height` of the ImageBackground was set to be 50%, it would be half the size of the current component it is in (as intended), but the Image would be 50% of the ImageBackground, which is only 25% the size of the ImageBackground's parent component.
Reviewed By: shergin
Differential Revision: D9307123
fbshipit-source-id: cec3802d30b72c44f66dd3a53693ebd669cc8db4
Summary:
When text nodes are nested, as below, `onPress` handlers need to be correctly invoked:
```
render() {
return (
<Text onPress={() => console.warn('hi')}>
hi
<Text onPress={() => console.warn('ramanpreet')}>ramanpreet</Text>
</Text>
);
}
```
In the above example, clicking on "hi" should warn "hi", and clicking on "ramanpreet" should warn "ramanpreet". This diff implements that behaviour.
Reviewed By: shergin
Differential Revision: D9696905
fbshipit-source-id: 2daf24e76c3b3c37aa36cd1540e54876a367faf7
Summary:
This diff includes two changes:
1. `TextShadowNode` represents virtual texts. For the time being, virtual text nodes only need touch capabilities so that they can handle `onPress` events for their children. Therefore, we should set the `TextShadowNode`'s `EventEmitterT` to `TouchEventEmitter`.
2. Since `ParagraphShadowNode` extends an instance of the `ConcreteViewShadowNode` template, it automatically uses the `ViewEventEmitter` if no event emitter is specified. I think it's better to make the event emitter explicitly specified. So, I've included that change in this diff.
Reviewed By: shergin
Differential Revision: D9696906
fbshipit-source-id: ac053ffdde4c2fbc6351f177c07a2ada4445cbb8
Summary:
This diff includes two changes:
1. Even though `RCTViewComponentView` conforms to `RCTTouchableComponentViewProtocol`, it never implemented this protocol. This diff makes the correction.
2. Make the necessary changes to `RCTSurfaceTouchHandler` required by the changes in `RCTTouchableComponentViewProtocol`. This means modifying the `ActiveTouch` struct to hold `SharedTouchEventEmitter`s. It also means passing in the touch point to the `componentView`'s `touchEventEmitterAtPoint` method.
Reviewed By: shergin
Differential Revision: D9696909
fbshipit-source-id: 3d4a833f7dbae6d0238a0807eb2220250ccbae3d
Summary: In the future, we may want some components (like Virtual Text) to handle only touch events. Therefore, I've extracted `TouchEventEmitter` from `ViewEventEmitter`.
Reviewed By: shergin
Differential Revision: D9696903
fbshipit-source-id: f6acc90d8ff53b5e6badaa472a5e099fb7cf03ff
Summary:
When a user clicks on some text, `RCTSurfaceTouchHandler` will call into a method on `RCTParagraphComponentView`. That method (i.e: `touchEventEmitter`) would be responsible for identifying the closest ancestral `<Text/>` component to which we should dispatch the `onPress` event, given the point where the user clicked. To answer this query, we'll use a data structure called `UIAttributedString`.
This data structure represents a string, and a corresponding mapping from sequences of its characters to some arbitrary data. In this attributed string, we'll map sequences of characters to their closest ancestral `ParagraphShadowNode` or `TextShadowNode`. That way, when we get a click event on `RCTParagraphComponentView`, we can just look at the character that was clicked, and use that information to do a lookup in the attributed string to find the shadow node who's EventEmitter is responsible for processing the click event.
Reviewed By: shergin
Differential Revision: D9696904
fbshipit-source-id: a199649981ad271afa85414ce4c3f056851348be
Summary: Previously, `BaseTextShadowNode::getAttributedString` used to recurse on a list of `SharedShadowNode`s (i.e: the children). In the `RawText` base case of this recursion, we'll need to record the parent of the current `RawText` (so that we can dispatch the `onPress` event to it). Therefore, we need to start recursing using the `SharedShadowNode` itself, and not its children.
Reviewed By: shergin
Differential Revision: D9696908
fbshipit-source-id: dbf3f9c21a7ae4de421d0355c4e5900b3947dc2a
Summary:
Switches to the `nullthrows` package instead of using `fbjs/lib/nullthrows`.
The version of `nullthrows` in `fbjs` is outdated and already missing features that exist in the standalone `nullthrows` package.
Also, this mitigates the inevitable collision between `nullthrows` (as a Haste module) and `nullthrows` (as a `node_modules` dependency).
Reviewed By: zertosh
Differential Revision: D9733178
fbshipit-source-id: 1b589d48c1ed57cebf2088b796ad72e212534c0a
Summary:
Motivation:
--------------
PR #20767 bumped the version of the Android Gradle Plugin to v3 which uses the newer Gradle dependency configurations `implementation` and `api` which make `compile` obsolete.
While the PR updated the template Gradle configuration, it did not cover the `link` command which will still link native modules using `compile` resulting in a warning message beeing displayed during an app build.
Since `compile` will be eventually removed by Gradle, this commit updates the `link` command to attach native modules using `implementation`.
Pull Request resolved: https://github.com/facebook/react-native/pull/20853
Differential Revision: D9733888
Pulled By: hramos
fbshipit-source-id: 22853480d7ba7be65e3387effda2fd6c72b6906a
