smp #1
Open
smp #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bigfootjon
force-pushed
the
master
branch
2 times, most recently
from
0dee0e6 to
1270873
Compare
Summary: Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D28595948 fbshipit-source-id: a12207f8e0c11e1e105225404450ff335242aba7
Summary: EventDispatcherImpl uses synchronized blocks all over to make it thread-safe. I'm concerned about the perf implications of this and creating contention between JS and UI threads. This is locked behind a feature flag. Enabled only for Fabric in StaticViewConfig mode, and a feature flag, for now. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D28591331 fbshipit-source-id: ea8f93a2e1343ce37fa78690dcb62fe03594120f
Summary: Changelog: [internal] Originally added in D17814260 (ffc7ec9) to make parallax effect work in Dating. This diff hides it behind a flag so we can properly evaluate what's the cost of sending scroll events to Paper. Reviewed By: JoshuaGross Differential Revision: D28608283 fbshipit-source-id: fa4d8944ad6b5e767363e231942f13fec9d18cb5
Summary: Changelog: [internal] My suggestion is to simplify event dispatching to only two options, synchronous and asynchronous. Why? - Fabric has only been using one queue, `AsynchronousBatched`. - Batching happens even on `AsynchronousUnbatched`. It just batches events until JS thread starts processing them instead of waiting for the main run loop. - It will make it easier to reason about the code in the future once we start utilising different priorities for Concurrent Mode. Reviewed By: JoshuaGross Differential Revision: D28603472 fbshipit-source-id: 14e3a9c15a012c550dc16a044c31d722051a2bdc
Summary: `isColorMeaningful` is the only place in xplat code that currently uses `colorComponentsFromColor`, which assumes that a color is an RGBA value. When implementing `PlatformColor` for windows, where colors might be complex patterns or effects, I'd like to keep the details of `SharedColor` isolated within `SharedColor`. This change moves `isColorMeaningful` into `color.cpp`, where each platform can provide an implementation that takes into account its platform specific color capabilities. See microsoft/react-native-windows#7801 for an example of window's SharedColor which can be either an RGBA value, or a name of a native color/brush. ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> [Internal] [Changed] - Move isColorMeaningful to platform specific code Pull Request resolved: #31557 Test Plan: This shouldn't change any of the code, its just moving the existing function - normal CI/automation should be plenty of validation. Reviewed By: JoshuaGross, sammy-SC Differential Revision: D28557698 Pulled By: mdvacca fbshipit-source-id: 2a94850fe9c5037598107e1307f4153cee6491fb
Reviewed By: zertosh Differential Revision: D28634989 fbshipit-source-id: 9e6397bfc0c4059877643bea7dcda6c42a4f4133
Summary: Android was using rawProps received from JS, so no updates needed. Updated iOS callsite to use the name of the action. Changelog: [General][Fixed] - Parse accessibilityAction props into object instead of string Reviewed By: mdvacca Differential Revision: D28614407 fbshipit-source-id: 209134f8fac65ca8516039e10ea502e57d52a7a7
Summary: Event.java's default implementation of `getCoalescingKey` returns 0. Most overrides of getCoalescingKey just return 0. Delete them. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D28650792 fbshipit-source-id: 374591fb4ba2305df934de412790b3397ca2fa1c
Summary: JS side expects the property name to be "actionName", and this change updates it to that. Changelog: [iOS][Fixed] - Use actionName in accessibility event callback Reviewed By: JoshuaGross Differential Revision: D28645999 fbshipit-source-id: 0e7a6c3e6c1b6c998f4b53fd89c744c84083dfb1
Summary: Upgrade jsc-android to latest stable version. Hopefully this should finally fix #25494. Before Hermes totally replaced JSC, it should be worth to have this and make JSC stable ## Changelog [Android] [Changed] - Upgrade jsc-android to 250230.2.1 Pull Request resolved: #31304 Test Plan: Launch app with new jsc-android and see everything works fine. Reviewed By: TheSavior Differential Revision: D28630503 Pulled By: yungsters fbshipit-source-id: 84510f91c81d4aaefe265d5492677ad6ff10e0fe
Summary: This sync includes the following changes: - **[316943091](facebook/react@316943091 )**: Make StrictMode double rendering flag static for FB/www ([#21517](facebook/react#21517)) //<Brian Vaughn>// - **[e0f89aa05](facebook/react@e0f89aa05 )**: Clean up Scheduler forks ([#20915](facebook/react#20915)) //<Ricky>// - **[5890e0e69](facebook/react@5890e0e69 )**: Remove data-reactroot from server rendering and hydration heuristic ([#20996](facebook/react#20996)) //<Sebastian Markbåge>// - **[46491dce9](facebook/react@46491dce9 )**: [Bugfix] Prevent already-committed setState callback from firing again during a rebase ([#21498](facebook/react#21498)) //<Andrew Clark>// - **[b770f7500](facebook/react@b770f7500 )**: lint-build: Infer format from artifact filename ([#21489](facebook/react#21489)) //<Andrew Clark>// - **[2bf4805e4](facebook/react@2bf4805e4 )**: Update entry point exports ([#21488](facebook/react#21488)) //<Brian Vaughn>// Changelog: [General][Changed] - React Native sync for revisions b8fda6c...ebcec3c jest_e2e[run_all_tests] Reviewed By: JoshuaGross Differential Revision: D28572047 fbshipit-source-id: eb09c0358edb7fbf241333ea9c08724748906fea
Summary: This sync includes the following changes: - **[459c34fde](facebook/react@459c34fde )**: Add flag concurrent root ([#21552](facebook/react#21552)) //<Samuel Susla>// Changelog: [General][Changed] - React Native sync for revisions 3169430...459c34f jest_e2e[run_all_tests] Reviewed By: mdvacca Differential Revision: D28641463 fbshipit-source-id: 0930a8f82e49b222582995e4c8b2c8a41564bf53
Summary: TL;DR: simplify and delete a bunch of stuff that shouldn't be necessary in Fabric. I discovered that this event dispatcher (and the older one this is based on) is triple-queueing: we queue events into "staging", and then post "dispatch events" to only run /on the JS thread/. Even in Fabric. Then, each of these events is emitted into C++ where they are queued /again/! This refactor eliminates one more level of queueing - instead of scheduling dispatch for the JS thread, we just emit them directly to C++ when they're received in Java. Unfortunately, the EventDispatcher is also used to drive AsyncEventBeat in C++: 1. EventBeatManager.onBatchEventDispatched: https://fburl.com/diffusion/qf6dyhsw In the C++ impl, it indirectly will drive the AsyncEventBeat/AsyncEventBeatV2. 2. onBatchEventDispatched is ONLY called from EventDispatcherImpl: https://fburl.com/codesearch/mxk8ifyj 3. Which is queued and only runs on the JS thread: https://fburl.com/codesearch/czvbst4u This means the AsyncEventBeat is only ticked when the JS thread is free, and ticks will be skipped when the JS thread is occupied for long periods. Now, in this refactor, when this class is used it will drive AsyncEventBeat on every UI tick. This is also potentially not correct. On iOS (Fabric), AsyncEventBeat is driven when the UI thread is "about to sleep". For now I'm not going to worry about that detail - it is significant, but Fabric+Android is currently /not doing the right thing/ and it's not clear that we want to maintain iOS behavior. This is something we need to discuss further and figure out. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D28654033 fbshipit-source-id: b3cb9b706343c8dd3c4cf84f24388908c57e2138
Summary: Changelog: [internal] Pulling out event queue processing to its separate class. We will be adding more logic there so it makes sense to separate it for simplicity and testability purposes. Alternative names that came to mind: `EventsProcessor`, `EventsDispatcher`. Reviewed By: JoshuaGross Differential Revision: D28572283 fbshipit-source-id: 1cb2459f616b9995f66da80d50c401e68002da7f
Summary: Changelog: [internal] Introduce a way to specify React priority for events. These APIs will be called from React here: https://github.com/facebook/react/blob/0e100ed00fb52cfd107db1d1081ef18fe4b9167f/packages/react-native-renderer/src/ReactFabricHostConfig.js#L345 React does similar thing on the web: https://github.com/facebook/react/blob/8ea11306ad473b26a2c899ef7a893d25413f3510/packages/react-dom/src/client/ReactDOMHostConfig.js#L378 Take a look at D28483983 that shows how React will be calling these APIs. Reviewed By: JoshuaGross Differential Revision: D28481260 fbshipit-source-id: c965a8aa0ba5192246c216046d49bcb046152a5a
Summary: Changelog: [internal] This is a mechanism that will guess event's React priority based on other events ongoing on the platform. If an event happens within span of ContinuousStart -> ContinuousEnd and its category is unspecified, we deduce it's React priority to be default. All other events are discrete. Special case: `onScroll`, which is always treated as "Default". Reviewed By: JoshuaGross Differential Revision: D28485060 fbshipit-source-id: d2eae63dbcf03271dfed97128a1590dd165a3ce2
Summary: Changelog: [internal] Introduces synchronous access to the runtime from RuntimeScheduler. At the moment, this is not used anywhere. In case RuntimeScheduler isn't defined (controlled by MC), falls back to RuntimeExecutor. Reviewed By: mdvacca Differential Revision: D28024380 fbshipit-source-id: 90be36dd390202540ed51940a4396040f043cd90
Summary: Replaces deprecated `translateX` and `translateY` props with `transform` prop in PanResponderExample. This fixes the RNTester example for react-native-windows, which doesn't support the deprecated props. Changelog: [General][Fixed] - [RNTester] Use transform prop in PanResponderExample Reviewed By: kacieb Differential Revision: D28676164 fbshipit-source-id: 437912b5abf6ca74f0043ded7a902a5938bcf93a
Summary: Changelog: [internal] Use getter function instead of accessing ivar. This makes for clearer APIs. React part is implemented in facebook/react#21553 Reviewed By: JoshuaGross Differential Revision: D28675372 fbshipit-source-id: cf99f8482067bfc0fd57d39fda9656abd665bb69
… native Summary: Changelog: [Fabric][iOS] Use non-global event emitter for onDismiss event for <Modal> Reviewed By: fkgozali Differential Revision: D28138741 fbshipit-source-id: df9069e523f2e8bd1b85f3d9be55cfd300f89d66
Summary: Changelog: [Internal] Add onDismiss tests for Modal Reviewed By: fkgozali, sammy-SC, nadiia Differential Revision: D28074384 fbshipit-source-id: 464c63cc9fe2d3e1709687369eea8cefd78d8356
Summary: This sync includes the following changes: - **[2d8d133e1](facebook/react@2d8d133e1 )**: Turn on enableSyncDefaultUpdates everywhere ([#21548](facebook/react#21548)) //<Ricky>// Changelog: [General][Changed] - React Native sync for revisions 459c34f...2d8d133 jest_e2e[run_all_tests] Reviewed By: gaearon Differential Revision: D28654355 fbshipit-source-id: c245f272e7f8d4215539fa90602b76cad67632fe
Summary: This diff updates the customDirectEvent types for ReactVitoImageManager changelog: [internal] internal Reviewed By: JoshuaGross Differential Revision: D28682669 fbshipit-source-id: 3341a7d6dbd5ec90f274f0770c6e883bd82f0a2d
Summary: Changelog: [internal] collapsable was not passed to Fabric because view configs are built using Paper' ViewManagers. Reviewed By: p-sun Differential Revision: D27944688 fbshipit-source-id: 73a5646e25b3dd7a1a9dfc1079406047ab483d88
Summary: 23d9bf1 looks like it accidently removed `localeIdentifier` from I18nManager. ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> [General] [Fixed] - Re-added localeIdentifier to I18nManager constants Pull Request resolved: #31589 Reviewed By: GijsWeterings Differential Revision: D28690202 Pulled By: fkgozali fbshipit-source-id: 543a491f89789bca5629e1251c94fd055ec4a801
Summary: Changelog: [internal] There is a possibility of race between updating scrollview's state and virtualised list asking for layout of individual cells. To make sure the race doesn't happen, state must be updated before dispatching onScroll event. Android has implemented a different mechanism to tackle this issue in D28558380 (b161241). Reviewed By: JoshuaGross Differential Revision: D28642737 fbshipit-source-id: 33874beac69fc5a66eeb7f459fd89cd0b00dafcf
…pass it to native" Summary: Changelog: [Internal] back out D28138741 (40706e0) Differential Revision: D28709374 fbshipit-source-id: c7085588ab4573c0ca18a2324f8e1ed40384753c
Summary: Add more detail about requesting review in the contribution guide. In the GAAD initiative it's particularly useful to know when certain PRs need our attention so wanted to highlight the code review process to remind contributors to request reviewers. ## Changelog [General] [Added] - Added more detail about the review process Pull Request resolved: #31590 Test Plan: Grammar, clarity review Reviewed By: TheSavior Differential Revision: D28719869 Pulled By: lunaleaps fbshipit-source-id: 9213fefbe602588f9e5cee7ba240b93bc7f291b5
Summary: Changelog: [Internal] Update title when navigating to an example Reviewed By: kacieb Differential Revision: D29545092 fbshipit-source-id: 7ce2f7d978601a5e11e2d60a8fd17be0249ce122
Summary: Changelog: [Internal] - Rename RNTesterHeader to RNTTitleBar Reviewed By: kacieb Differential Revision: D29571325 fbshipit-source-id: 192b73af63f2e924c8beb55e96855ebfe9afa6fb
Summary: Changelog: [Internal] Fix things in RNTester * Make SectionList-contentInset example iOS only and update styling * Fix a typo in SectionList-onEndReached example * Fix module example styling and pressed state styling for Android Reviewed By: kacieb Differential Revision: D29571327 fbshipit-source-id: 5cbb68781536e21ca73ca22b01343379306babd4
…vent Summary: I suspect that T94864568 is caused by TouchEvents being dispatched after they've been recycled. This needs further analysis, but to stop the bleeding, we can drop events at the point they'd be dispatched before the crash, and log a soft error. Changelog: [Internal] Reviewed By: ShikaSD Differential Revision: D29594749 fbshipit-source-id: f50df8df2125b83126616ceaf4e529127d154c7c
Summary: As a followup to T91209139, ship "state update scroll race" in code. This also ships it for HorizontalScrollView since it's been validated for vertical scroll views. Changelog: [Internal] Reviewed By: sammy-SC Differential Revision: D29595601 fbshipit-source-id: 64b6a23e2dab2c13123e132d9d899fb769d03172
#29809) Summary: iOS 13 added a new property to `UIScrollView`: `automaticallyAdjustsScrollIndicatorInsets`, which is `YES` by default. The property changes the meaning of the `scrollIndicatorInsets` property. When `YES`, any such insets are **in addition to** whatever insets would be applied by the device's safe area. When `NO`, the iOS <13 behavior is restored, which is for such insets to not account for safe area. In other words, this effects ScrollViews that underlay the device's safe area (i.e. under the notch). When `YES`, the OS "automatically" insets the scroll indicators, when `NO` it does not. There are two problems with the default `YES` setting: 1. It means applying `scrollIndicatorInsets` to a `ScrollView` has a different effect on iOS 13 versus iOS 12. 2. It limits developers' control over `scrollIndicatorInsets`. Since negative insets are not supported, if the insets the OS chooses are too large for your app, you cannot fix it. Further explanation & sample code is available in issue #28140 . This change sets the default for this property to `NO`, making the behavior consistent across iOS versions, and allowing developers full control. ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> [iOS] [Changed] - ScrollView scrollIndicatorInsets to not automatically add safe area on iOS13+ Pull Request resolved: #29809 Test Plan: Updated the RNTester example to explain what to expect. Also removed the `pageScreen` modal example for now as mentioned in my Github comment. {F628636466} Here are screenshots of the demo app (from the original bug) before (with safe area applied to insets) & after (without safe area applied to insets):   Reviewed By: p-sun Differential Revision: D28229603 Pulled By: lunaleaps fbshipit-source-id: 2e774ae150b1dc41680b8b7886c7ceac8808136a
Summary: Add animation queuing back into createAnimatedComponent_EXPERIMENTAL.js, which is a concurrent-safe version of createAnimatedComponent. T93269035 for details on why this is needed. # How does this work? In the old createAnimatedComponent, Animations were queued by calling `setWaitingForIdentifier` before render, and then calling `unsetWaitingForIdentifier` after render. In this diff, instead we are calling `setWaitingForIdentifier` in an `useLayoutEffect` before calling `useAnimatedProps`, and we are calling `unsetWaitingForIdentifier` in a `useEffect` after `useAnimatedProps`. So the ordering for the effects are: 1. `useLayoutEffect` with `setWaiting` 2. `useLayoutEffect`s in `useAnimatedProps` 3. `useEffect`s in `useAnimatedProps` 4. `useEffect` with `unsetWaiting`. There's a React guarantee that **if one effect is called, all of them will be called**, so we don't have a concern about the queue getting locked. ## **Main concerns:** 1. This works in my test cases, but it's not the same behavior as the old createAnimatedComponent (which is wait before and unset wait after render). This may still be ok because the relevant side effects in render from that component have been moved to `useLayoutEffect` or `useEffect` in `useAnimatedProps` (so the ordering is still the same?). 2. I'm not sure about the ordering of `onLayoutEffect`, `onLayout` callbacks, and `useEffect`. createAnimatedComponent_EXPERIMENTAL doesn't use `onLayout`, but with this new method of queuing, **`onLayout` calls will likely be called before the animation queue has been flushed**. It's not clear to me whether this is bad. Changelog: [Internal] Reviewed By: yungsters Differential Revision: D29467458 fbshipit-source-id: 2be23a8968404526d0fa394a7879fda8b5ffbfdc
…mponent Summary: Code almost directly copied from the old implementation of [createAnimatedComponent.js](https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/Libraries/Animated/createAnimatedComponent.js?commit=156dbfe5d0fc491819a8b4939896d23b2273e251&lines=208-211). This is necessary for certain things to work (like ScrollViewStickyHeader). The reason is because when animations are driven by useNativeDriver, JS does not know where the component has moved to. If a component that is translated like ScrollViewStickyHeader is also Pressable, the onPress will **not** work without this prop. [Link to where ScrollViewStickyHeader uses passthroughAnimatedPropsExplicitValues](https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/Libraries/Components/ScrollView/ScrollViewStickyHeader.js?commit=124a38e1708b620857e4e6969cdef6004aa1bd10&lines=294-296) I am not adding this to the Flow type because we only want people using this if they really know what they're doing, as it's a hacky fix. Followup work to this would be to create a hook to attach the listener to the animated values, which ScrollViewStickyHeader does manually. But this is not required for this component to work. Changelog: Internal Reviewed By: yungsters Differential Revision: D29557480 fbshipit-source-id: 293fab4746c3404f5ae9b90afe85d2ca91181873
Summary: It is possible for receiveEvent to be called concurrently with/after destruction of FabricUIManager. Drop events if we are able to detect that case. Changelog: [Internal] Reviewed By: sshic Differential Revision: D29596271 fbshipit-source-id: 1fa50d9c3cff0bf578316d905966e1bdfffe94d1
…ager.getViewManagerNames method Summary: This diff fixes a NullPointerException that is caused when the method ReactInstanceManager.getViewManagerNames is called at the same time ReactInstanceManager is being destroyed. Following the stacktrace I noticed that this crash can only happen when RN was destroyed by another thread while this method was being executed This diff fixes the NullPointerException, but it doesn't fix the root cause race condition that cuases this bug changelog: [Android][Fixed] Fix NullPointerException caused by race condition in ReactInstanceManager.getViewManagerNames method Reviewed By: JoshuaGross Differential Revision: D29616401 fbshipit-source-id: 6ae8ecdd765d2fe3529fef3237f08b182d8ed243
Summary: At risk of hiding errors, given the low volume, I think it's safe to cause this to crash in debug and continue gracefully in release-mode. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D29618047 fbshipit-source-id: 19b19d8f6e27703227de4947ed01f7f2177f463b
…lPointerException: bio == null crash (#31822) Summary: Douring our routine crash report check we are occasionally seeing reports of exceptions like this in the wild from our crash stack: ``` java.lang.NullPointerException: bio == null at com.android.org.conscrypt.NativeCrypto.SSL_pending_written_bytes_in_BIO(NativeCrypto.java) at com.android.org.conscrypt.NativeSsl$BioWrapper.getPendingWrittenBytes(NativeSsl.java:660) at com.android.org.conscrypt.ConscryptEngine.pendingOutboundEncryptedBytes(ConscryptEngine.java:566) at com.android.org.conscrypt.ConscryptEngineSocket.drainOutgoingQueue(ConscryptEngineSocket.java:584) at com.android.org.conscrypt.ConscryptEngineSocket.close(ConscryptEngineSocket.java:480) at okhttp3.internal.Util.closeQuietly(Util.kt:501) at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFile:245) at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFile:106) at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFile:74) at okhttp3.internal.connection.RealCall.initExchange$okhttp(ExchangeFile:255) at okhttp3.internal.connection.ConnectInterceptor.intercept(ExchangeFile:32) ... ```  This appears to only be happening on devices running Android 10 and 11. This happens because there is concurrency issue in Conscrypt where two threads race to close an SSLEngine-based SSLSocket and access to the underlying BIO is unsynchronized. **The OkHttp team already released a fix for this issue on version 4.9.1** this PR aims to update our OkHttp package to version 4.9.1. Related discussion: [https://issuetracker.google.com/issues/177450597](https://issuetracker.google.com/issues/177450597) [https://publicobject.com/2021/01/30/bio-null/](https://publicobject.com/2021/01/30/bio-null/) cc dulmandakh fkgozali ## Changelog [Android] [Changed] - Bumping OkHttp from 4.9.0 to 4.9.1. Pull Request resolved: #31822 Test Plan: Manual & Automated from CI Reviewed By: fkgozali Differential Revision: D29590198 Pulled By: ShikaSD fbshipit-source-id: 4228bfd3472114253e13acb436dc1dd9287a148d
Summary: Latest Android Gradle plugin doesn't respond to ANDROID_NDK env variable, so I propagated it explicitly and included with recommended `ndkPath` clause. Changelog: [Internal] allow-large-files Reviewed By: fkgozali Differential Revision: D29593132 fbshipit-source-id: 0785fe92385037d2d4cf290c2462b299800b6928
Summary: Pull Request resolved: #31772 Changelog:[General][Removed] - Remove Picker iOS code Reviewed By: p-sun Differential Revision: D29124724 fbshipit-source-id: d3b3a409961cf04e2cd079a91986d30e3166dcda
Summary: Gradle cannot find the property, because it is defined conditionally depending on env variable. We want the default for it to be null instead, so the variable exists but doesn't change default NDK location. Changelog: [Internal] Reviewed By: motiz88 Differential Revision: D29634984 fbshipit-source-id: 4cf40a1c8d20b2f9008a637456bf9d228d2959d3
Summary: Issue #30964 .When using a screen reader, flatlist does not announce entrance/ exit from the flat list. ## Changelog [Android] [Changed] - Added support for accessibility role of "list" for flatlist and sectioned list Pull Request resolved: #31630 Test Plan: I have added accessibility role prop in flatlist and sectioned list in rntester app, that will announce entrance/ exit from flatlist and sectioned list. Reviewed By: kacieb Differential Revision: D29599351 Pulled By: blavalla fbshipit-source-id: e16ec69a694780d12f15f88a1e6bb5d7d77ac15f
Summary: This is a followup to D29514800. Changelog: [Internal] Reviewed By: motiz88 Differential Revision: D29647688 fbshipit-source-id: d6b7be96f4e0ec6ae97c11685be7e44a558116f2
Summary: Could not repro myself, but logview shows steady low number of crashes coming from this mid. Current fix returns early if the layout is not defined, relying on the following layout passes to position view correctly. Changelog: [Android][Fixed] Exit early from layout in textview if text layout is null Reviewed By: JoshuaGross Differential Revision: D29636040 fbshipit-source-id: 876ce80222cbc5ff09450224f6808f9f6433c62a
Summary: Building from source in debug takes a very long time because native builds need to run for all supported architectures. It is possible to check which architecture the devices for which we are about to launch the app on are and build only for those. For most cases we can reduce the number of architectures we build for to 1 instead of 4, resulting in a large speedup of the build. This is inspired by iOS which has a "Build for active architecture only" option. Since android doesn't really support this natively we can implement it here and also in react-native by reading the build properties that we pass and alter the abi we build for. With fabric / codegen coming up I suspect that we might want to default to building c++ soon. This should ease the transition as builds won't be orders of magnitude slower. See react-native-community/cli#1388 for more context and how we use this new config to automatically detect running emulator architectures. ## Changelog [Android] [Added] - Allow configuring ndk build architectures Pull Request resolved: #31232 Test Plan: Tested by setting reactNativeDebugArchitectures with different values in gradle.properties. Checked the build logs to see which architectures are being built. Also made sure release builds are not affected by this value. Clean build reactNativeDebugArchitectures not set 824.41s reactNativeDebugArchitectures=x86 299.77s Reviewed By: mdvacca Differential Revision: D29613939 Pulled By: ShikaSD fbshipit-source-id: d20a23d1d9bbf33f5afaaf3475f208a2e48c0e1a
…id TV (#31837) Summary: Add MEDIA_STOP, MEDIA_NEXT, and MEDIA_PREVIOUS event support to Android TV (TVEventHandler) ## Changelog [Android] [Added] - Add MEDIA_STOP, MEDIA_NEXT, and MEDIA_PREVIOUS event support to Android TV Pull Request resolved: #31837 Test Plan: We develop application that utilizes aforementioned events, we've made a build against react-native fork with these changes and it was working as expected. These changes just add 3 more button mappings, so I don't think it requires some extensive testing. Reviewed By: TheSavior Differential Revision: D29668706 Pulled By: yungsters fbshipit-source-id: e4bd8dcf7de6b094ffdbbca12d875b85e468d49a
Summary: Refactors how `Typeface` style and weight are applied in React Native on Android. - Unifies all style and weight normalization logic into a new `TypefaceStyle` class. - Fixes font weight support for the Fabric renderer. - De-duplicates code with `TextAttributeProps`. - Simplified normalization logic. - Fixes a rare crash due to `Typeface.sDefaultTypeface` (Android SDK) being `null`. - Adds a new example to test font weights in `TextInput`. - Adds missing `Nullsafe` and `Nullable` annotations. - Clean up a bunch of obsolete inline comments. Changelog: [Android][Fixed] - Fixed a rare crash due to `Typeface.sDefaultTypeface` (Android SDK) being `null`. [Android][Fixed] - Fixed font weight support for the Fabric renderer. [Android][Added] - Added a new example to test font weights in `TextInput`. Reviewed By: JoshuaGross Differential Revision: D29631134 fbshipit-source-id: 3f227d84253104fa828a5561b77ba7a9cbc030c4
Summary: This changeset is limited to whitespace and reordering changes that have no effect on the output or execution of the script. The sole purpose of this changeset is to apply these trivial changes prior to making some larger adjustments to the script in a followup. With these changes, the ordering of statements more closely matches the order they are executed in (e.g. prepare_command before the script_phase). Changelog: [Internal] Reviewed By: RSNara Differential Revision: D29527804 fbshipit-source-id: d161ed31321d68baf420457c7aa0aa23a6fc98d2
Summary: Extend the codegen script to allow arbitrary library name to be passed along as an argument, as well as the desired output directory for TurboModules and Fabric output. New arguments: - `:library_name` - `:modules_output_dir` - `:components_output_dir` These arguments remain optional, and in their absence, the codegen will generate output that should work for the FBReactNativeSpec core native modules use case. Internally, the script has been updated to use the correct path for the core modules use case as well as third party modules. Changelog: [Internal] - Extend the codegen script to take additional parameters Reviewed By: RSNara Differential Revision: D29243707 fbshipit-source-id: 1921bd3e5fd62d7cbf4c8b5089acfdd112f4b014
Summary: Adjustments to ensure RNTester compiles successfully. [Internal] - RNTester Xcode project adjustments Reviewed By: RSNara Differential Revision: D29525295 fbshipit-source-id: df532bd66d50471c4baf63629eb90b4ca4105127
Summary: Pull Request resolved: #31856 Upgrades `infer-annotation` to 0.18.0 so that we can use `Nullsafe` in Android Java. I found this when looking at the "Bazel" steps on this page: https://search.maven.org/artifact/com.facebook.infer.annotation/infer-annotation/0.18.0/jar Changelog: [Android][Changed] - Upgraded `infer-annotation` to 0.18.0. Reviewed By: mdvacca, ShikaSD Differential Revision: D29685321 fbshipit-source-id: a017ad29355c4790bffa8bcd349336e51261f83e
Summary: Issue #31604 . Remove `defaultProps` from `SegmentedControlIOS`. ## Changelog [JavaScript] [Changed] - Remove defaultProps from SegmentedControlIOS Pull Request resolved: #31804 Test Plan: Added tests for `SegmentedControlIOS` pass. Reviewed By: yungsters Differential Revision: D29653982 Pulled By: lunaleaps fbshipit-source-id: ed6e133cc3af629be6cd83be79e402ad1e68b29b
Summary: Update flow version to v0.155.0 Changelog: [Internal] Reviewed By: pieterv Differential Revision: D29641055 fbshipit-source-id: 601a82fe4fa4ce548a790347a84aea4014c418d9
Summary: Fixes #31774. This pull request resolves a problem related to accessing blobs greater than 64 KB on Android. When an object URL for such blob is passed as source of `<Image />` component, the image does not load. This issue was related to the fact that pipe buffer has a limited capacity of 65536 bytes (https://man7.org/linux/man-pages/man7/pipe.7.html, section "Pipe capacity"). If there is more bytes to be written than free space in the buffer left, the write operation blocks and waits until the content is read from the pipe. The current implementation of `BlobProvider.openFile` first creates a pipe, then writes the blob data to the pipe and finally returns the read side descriptor of the pipe. For blobs larger than 64 KB, the write operation will block forever, because there are no readers to empty the buffer. https://github.com/facebook/react-native/blob/41ecccefcf16ac8bcf858dd955af709eb20f7e4a/ReactAndroid/src/main/java/com/facebook/react/modules/blob/BlobProvider.java#L86-L95 This pull request moves the write operation to a separate thread. The read side descriptor is returned immediately so that both writer and reader can work simultaneously. Reading from the pipe empties the buffer and allows the next chunks to be written. ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> [Android] [Fixed] - Fix support for blobs larger than 64 KB Pull Request resolved: #31789 Test Plan: A new example has been added to RN Tester app to verify if the new implementation properly loads the image of size 455 KB from a blob via object URL passed as image source. <img src="https://user-images.githubusercontent.com/20516055/123859163-9eba6d80-d924-11eb-8a09-2b1f353bb968.png" alt="Screenshot_1624996413" width="300" /> Reviewed By: ShikaSD Differential Revision: D29674273 Pulled By: yungsters fbshipit-source-id: e0ac3ec0a23690b05ab843061803f95f7666c0db
… exception Summary: This is crashing too much in debug, which is good signal but making it harder to test, and test unrelated features. We have some good data about this internally and validated that it's useful; we can follow up on the logged soft exceptions without actually crashing now. Changelog: [Internal] Differential Revision: D29698447 fbshipit-source-id: 61387c18f17f76e5de60baa1fd3c94028229c0f6
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Changelog
[CATEGORY] [TYPE] - Message
Test Plan