Summary:
There's a very old issue with reload logic: invalidation and resetting up of the bridge could be racing. In this case, we hit a redbox when:
* Chrome debugger is enabled in previous app run, then we launch the app again
* The bridge starts, then immediately reloads itself to connect to Chrome
* On the 2nd setup, the logic to update the green loading bar, with the % indicator for loading off metro, failed to find the DevLoadingView module instance because the bridge is in the middle of invalidating
See https://github.com/facebook/react-native/issues/23235
To test:
Using react-native init from github, do the steps in https://github.com/facebook/react-native/issues/23235, no more redbox. Note that the loading indicator % won't be proper still, but at least it doesn't crash/redbox.
Reviewed By: JoshuaGross
Differential Revision: D14110814
fbshipit-source-id: 835061e50acc6968bffbcc2ddfbe8da79a100df9
Summary:
When using building React Native using the `.xcodeproj` (either via linked projects in Xcode, or precompiling React Native, which is what we do), you'll get a duplicate symbol error:
```
duplicate symbol __ZN8facebook5react10IInspectorD0Ev ...
```
And a few more.
This is because the `InspectorInterfaces.cpp` file is included in _both_ the `React` target _and_ the `jsinspector` target, and since the `jsinspector` target gets linked into the `React` target, this means the symbols from `InspectorInterfaces.cpp` end up in `libReact.a` twice.
<img width="187" alt="screen shot 2019-02-04 at 11 43 39 am" src="https://user-images.githubusercontent.com/819705/52189088-93190880-288a-11e9-8411-b44b59e8e461.png">
This PR removes `InspectorInterfaces.cpp` from the `React` target, as I believe was the original intent.
Since this bug is in the `xcodeproj` it only affects builds that use that, so CocoaPods and Buck users are unaffected.
[iOS][Fixed] - Fix potential linker issues when using xcode project
Pull Request resolved: https://github.com/facebook/react-native/pull/23284
Differential Revision: D13941777
Pulled By: cpojer
fbshipit-source-id: 8a3ffb4fc916ff6570bbff8794b4515b48055667
Summary:
Fixes#22530
As described in the issue, the previous behavior for the `RCTFatal` macro was to truncate the `reason` on the resulting `NSException` to 75 characters. This would ensure the reason would fit on a single line, but resulted in issues debugging errors that occurred in the wild, as many crash logging tools (like Sentry) discard the `name` value of the exception and use the `reason` as their primary identifier. At 75 characters, useful information like the location of the error would usually be truncated.
- [x] This extends the truncation threshold to 175 characters, which should be short enough to prevent full-screen-takeover length errors, but long enough to provide useful context to the error.
- [x] This adds a `userInfo` value to the resulting `NSException`. It copies over the `userInfo` from the `NSError` passed to the macro, and adds an "untruncated message" value that contains the untruncated version of the `NSException`'s reason.
[iOS] [Changed] - RCTFatalExceptions now include more information in their reason and a userInfo.
<!--
CATEGORY may be:
- [General]
- [iOS]
- [Android]
TYPE may be:
- [Added] for new features.
- [Changed] for changes in existing functionality.
- [Deprecated] for soon-to-be removed features.
- [Removed] for now removed features.
- [Fixed] for any bug fixes.
- [Security] in case of vulnerabilities.
For more detail, see https://keepachangelog.com/en/1.0.0/#how
MESSAGE may answer "what and why" on a feature level. Use this to briefly tell React Native users about notable changes.
EXAMPLES:
[General] [Added] - Add snapToOffsets prop to ScrollView component
[General] [Fixed] - Fix various issues in snapToInterval on ScrollView component
[iOS] [Fixed] - Fix crash in RCTImagePicker
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/22532
Differential Revision: D13373469
Pulled By: cpojer
fbshipit-source-id: ac140d14ce76e1664869437c2c178bdd65ab6e0e
Calling -[UIScrollView setContentOffset] with NaN values can cause a crash. That's not clear why exactly the computation returns NaN sometime, but the implemented sanitizing should help to detect this problem during development (and this also prevents the app from crashing).
See attached task for more details.
Reviewed By: fkgozali
Differential Revision: D13242729
fbshipit-source-id: 747bf1b42e02597e9f1300eee24547563ab29b27
Summary: Future::then taking a value-taking function is deprecated and being deleted. This cleans up a few more callsites.
Reviewed By: yfeldblum, shergin
Differential Revision: D13163277
fbshipit-source-id: 98d1f78c5b34ca34603cc24d79157a4718573576
Summary:
If text is truncated and an inline view appears after the truncation point, the user should not see the inline view. Instead, we have a bug such that the inline view is always visible at the end of the visible text.
This commit fixes this by marking the inline view as hidden if it appears after the truncation point.
This appears to be a regression. React Native used to have logic similar to what this commit is adding: https://github.com/facebook/react-native/blob/1e2a924ba60001c6f0587c7561536f00b2922cbf/Libraries/Text/RCTShadowText.m#L186-L192
**Before fix**
Inline view (blue square) is visible even though it appears after the truncation point:
The full text being rendered was:
```
<Text numberOfLines={1}>
Lorem ipsum dolor sit amet, consectetur adipiscing elit,
sed do eiusmod tempor incididunt ut labore et dolore magna
<View style={{width: 50, height: 50, backgroundColor: 'steelblue'}} />
</Text>
```
**After fix**
Inline view is properly truncated:
**Test Plan**
Tested that the inline view is hidden if it appears after the truncation point when `numberOfLines` is 1 and 2. Similarly, verified that the inline view is visible if it appears before the truncation point.
**Release Notes**
[IOS] [BUGFIX] [Text] - Fix case where inline view is visible even though it should have been truncated
Adam Comella
Microsoft Corp.
Pull Request resolved: https://github.com/facebook/react-native/pull/21456
Differential Revision: D10182991
Pulled By: shergin
fbshipit-source-id: a5bddddb1bb8672b61d4feaa04013a92c8224155
Summary:
Update reference to property in code comment in `RCTBridgeModule`. There is no such thing as `requiresMainThreadSetup` in the codebase. Its called `requiresMainQueueSetup` now.
Pull Request resolved: https://github.com/facebook/react-native/pull/22328
Differential Revision: D13115352
Pulled By: shergin
fbshipit-source-id: 511d627388b51029821c4b1ddf4caac30e573040
Summary: That's a temporary change that useful only while we don't have deeper/proper intergration with UIKit's navigation infra.
Reviewed By: mdvacca
Differential Revision: D13104172
fbshipit-source-id: 024e71e04470d56d2c5e9b3f6c3392555ce50b63
Summary:
Apparently, if a gesture recognizer got 'reset', OS does not call `touchesCancelled:` method, so we have to do it manually.
To implement this we have to split `_dispatchTouches:eventType:` into two methods: the first converts Objective-C touches to C++ touches, the second consumes that. We have to do this because during reset we don't have a collection of UIKit touches.
Reviewed By: mdvacca
Differential Revision: D13072807
fbshipit-source-id: 677e2febf9f96dcdfaadfadf5b9ab3893f93e796
Summary: Every C++ engineer (except me several months ago) knows that `operator []` can mutate the collection (Yeah! Don't ask), so this is especially dangerous if your hash function is broken (see the previous diff).
Reviewed By: mdvacca
Differential Revision: D13072805
fbshipit-source-id: 4436a8ff12fb27a57bfb6ee0ff986d7a9a825549
Summary:
Without this fix the PointerHasher hashed not a pointer, but an address where the pointer is stored, which is obviously incorrect.
The incorrect hash function compromised the whole `_activeTouches` caused many issues with logically invalid invariants (e.g. removing element from the collection silently didn't work).
Reviewed By: mdvacca
Differential Revision: D13072804
fbshipit-source-id: d68289e940fe21e2df08a31439619b7e2fe0fa13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/22316
Pull Request resolved: https://github.com/facebook/react-native/pull/22315
In order for TLS Mutual Auth to work for webviews, the caller must present a credential. Expose a setter that can be called to set a credential.
Reviewed By: RSNara
Differential Revision: D13095969
fbshipit-source-id: d136556a0030f799651d574b6e47ce38295b108e
Summary:
Now, Objective-C part of RN is in `xplat` directory, so global Objective-C clang-format does not affect that.
Explicit clang-format is also useful for external contributors who don't have access to the rest of monorepo.
The actual rules are copy-paste from ReactCommon folder with small changes (like 120 characters max line length) that conform to regular Facebook code style and which make sense only for Objective-C.
Reviewed By: fkgozali
Differential Revision: D13093150
fbshipit-source-id: 79d64b4fba6eeb94e9b8d87ef9c3f86b3a5ed94e
Summary:
Some module classes may not be loaded yet, so looking up via classes may not always give the correct instance. This diff added a new lookup method that delegate to the bridge delegate to force load the modules as needed.
The existing moduleForName: method was left untouched because it's solely used by RCTUIManager at the moment.
Reviewed By: dshahidehpour
Differential Revision: D13033876
fbshipit-source-id: 4082fcd68498004f678b4b95adc82b5b134fefdf
Summary: This diff changes the behavior of the Scheduler.schedulerDidRequestPreliminaryViewAllocation to avoid pre-allocating views that are non-layoutables
Reviewed By: shergin
Differential Revision: D12962008
fbshipit-source-id: cb2670beafdcbd2116fbdaf2dc5d1b4726330ec2
Summary: We are moving to more stable APIs removing all mentiones of the effort name from the codebase.
Reviewed By: mdvacca
Differential Revision: D12912894
fbshipit-source-id: 4a0c6b9e7454b8b14e62d419e9e9311dc0c56e7a
Summary:
D12911108 fixed a UBN race condition by adding a flag for module registry.
This flag was never reset if react instance gets reset, causing an assert to fire in IG.
Reviewed By: fkgozali
Differential Revision: D13010651
fbshipit-source-id: e20453f3c546d759a58fd7fb93553f774410905f
Summary: Depending on when Chrome debugger is attached, modules may get double registered. Simply ignore it for this case. The redbox was not a fatal error, which can be dismissed.
Reviewed By: shergin
Differential Revision: D12996107
fbshipit-source-id: 292f63102337077848842ca46b3daed08b1cae12
Summary:
it's possible that moduleForName won't return anything, so we should return.
Created from Diffusion's 'Open in Editor' feature.
Reviewed By: spredolac
Differential Revision: D12963342
fbshipit-source-id: c059595a68bfcaa38221e05fb62d70cc29887ca7
Summary:
It does not supported on Android and nobody uses it.
I could find only one use cases: Very old versin of `SectionList` library (4 years ago).
Reviewed By: sahrens
Differential Revision: D12972361
fbshipit-source-id: a5dfef5e877e996adec2d4941417b4a2e727cfb7
Summary: This diff exposes rootTag as part of SchedulerDelegate.schedulerDidRequestPreliminaryViewAllocation(). This will be necessary to be able to pool views per Surface in Android
Reviewed By: shergin
Differential Revision: D12875656
fbshipit-source-id: d2a8c1f9bcc6b14c17b34bf59085da44ae3c3416
Summary: Before lazily-loading code existed, modules that were already loaded into memory took precedent over modules that were additionally registered. With lazily loading modules, instead of giving eagerly loaded modules precdence, it throws a redbox. This diff fixes that behavior.
Reviewed By: PeteTheHeat
Differential Revision: D12983805
fbshipit-source-id: fe4fcf35d5c2ca6f9f4e3f0d1d8c2ca35468fb1b
