Summary:
Recently, we changed the logic to verify the body of a PR so that it is more compatible internally and externally, in both ways. But we forgot to update the template, so right
now, all the created PR are incompatible with the internal PR checker.
The required change is to have `:` after the Changelog title.
For consistency, I added the `:` after ALL the titles.
## Changelog:
[Internal] - Changed the PR template to align it to the new rules
Pull Request resolved: https://github.com/facebook/react-native/pull/36705
Test Plan: No danger errors nor internal linter errors
Reviewed By: christophpurrer
Differential Revision: D44503519
Pulled By: cipolleschi
fbshipit-source-id: 43963c3cf774d19d6de8e86b18b684e76dd0fe87
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36699
Changelog: [internal]
This fixes a crash introduced in D43692171 where `jsi::Pointer` outlives `jsi::Runtime` in which it was created. This leads to a crash.
The diff changed ownership model, retaining `TextLayoutManager` strongly from `ParagraphState`.
To resolve this, in this diff we change how `StateWrapperImpl` owns state, moving from shared_ptr to weak_ptr. We have tried to do it previously in D26815275 but it had to be reverted because it broke end to end tests. I made sure the tests are fine. However it is the right ownership model. Java objects should not strongly hold onto anything in ShadowTree. If ShadowTree is destroyed, Java calls should noop, not keep objects in memory and have them handle the case when runtime was destroyed.
jest_e2e[run_all_tests]
Reviewed By: cipolleschi
Differential Revision: D44472121
fbshipit-source-id: 83b79329440ac1211902ea9511c0dde9a77ab9e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36702
With the monorepo changes we broke the build from source for users.
This fixes it so that folks can just follow the guide:
https://reactnative.dev/contributing/how-to-build-from-source
Changelog:
[Android] [Fixed] - Fix the setup to allow the build-from-source on host projects
Reviewed By: cipolleschi
Differential Revision: D44502428
fbshipit-source-id: 3ad8fb114f5e2f7ffdf6fffa617ceaa45334f5f3
Summary:
Adds changelog for new patch.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.71.5
Pull Request resolved: https://github.com/facebook/react-native/pull/36698
Test Plan: N/A
Reviewed By: christophpurrer
Differential Revision: D44502179
Pulled By: cipolleschi
fbshipit-source-id: fe0470ccc067966af3a98e6959702ca26c7af6db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36696
As the title says, we're converting the new app template to Kotlin.
This will reduce the template size and make it more aligned to market standards.
Changelog:
[Android] [Changed] - Convert the app template to Kotlin
Reviewed By: mdvacca
Differential Revision: D44142081
fbshipit-source-id: 6111360b6580460eba0341e47c55704cc673e444
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36692
Similar to the iOS counterpart,
this changes adds an example to RNTester to verify that the Interop Layer can process bubbling events in Fabric as it used to do in Paper.
Changelog:
[Internal] [Changed] - Add Fabric Interop event example
Reviewed By: cipolleschi
Differential Revision: D44467555
fbshipit-source-id: 1f1af27583c402641c549bc2926a64469dcd7b3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36693
Similar to #36417, this changes adds an example to RNTester to verify that the Interop Layer can process constants in Fabric as it used to do in Paper for Android.
Changelog:
[Android] [Added] - Add Fabric Interop constants example
Reviewed By: cipolleschi
Differential Revision: D44466391
fbshipit-source-id: 74e654319b93e60b415297dcdddc98eb100913df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36672
Changelog: [Internal]
if we look at usages of ReactModuleWithSpec, we see that it's existence was to simply identify generated native modules since the inheritance graph of native modules was different if they were generated.
this was introduced before we created the TurboModule interface, which all codegenned native modules also conform to. since that exists now, there's no need for both of these. this is the only callsite in our code where ReactModuleWithSpec triggers any logic, so i'm updating it.
bypass-github-export-checks
Reviewed By: javache
Differential Revision: D44450687
fbshipit-source-id: f9c26fce8e360b6e319153aad83fc788079bac91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36671
Changelog: [Internal]
BaseJavaModuleTest tests the reflection of the native module methods wrapped by the JavaModuleWrapper abstraction, this abstraction is used by JNI in the C++ layer.
however, though we already have logic that supports the reflection of our codegenned modules (turbomodules), we didn't have a test for it yet, so i'm adding it in this change.
Reviewed By: javache, cortinico
Differential Revision: D44450433
fbshipit-source-id: 44abcf188d4b0559c684a95b058bd55e082b5531
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36614
Changelog: [Internal] - Ensure Pressability doesn't forward onClick to onPress when it receives a click via pointer events.
This is a better version of D43128801 which ensures that click events which are triggered by the new pointer events event emitter don't trigger onPress in Pressability — avoiding the double onPress issue while ensuring all existing usecases of onClick continue to work.
Reviewed By: yungsters
Differential Revision: D44031433
fbshipit-source-id: 5ecdd132f7f91338c5a3632c05510f96495b512e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36670
Changelog: [Internal]
so powermock doesn't have compatibility with JDK 18 (not sure what RN is on), but regardless my understanding is that we should be moving away from powermock since it's not maintained anymore.
this test was disabled because of that so this should allow it to run again.
Reviewed By: javache, cortinico
Differential Revision: D44445586
fbshipit-source-id: f9cabe80332a9ef11df690ac2af20bd60bb61641
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36687
## Changelog:
This apparently fell into the cracks during the recent (awesome! :)) monorepo migration, as the result the tests set for `WebPerformance` became empty.
Reviewed By: hoxyq
Differential Revision: D44466070
fbshipit-source-id: b13a696e73b18823f975946e8bc2e99d800d8891
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36686
After the recent changes of Metro and Metro-Config, we need to update the path used to load the bundle in RNTester
## Changelog:
[General][Fixed] - Use the right path to load RNTester bundle
Reviewed By: cortinico
Differential Revision: D44465418
fbshipit-source-id: 96170194579792f9a5d8a141328d43e45a4db973
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36681
This change is needed to add some E2E tests on the Hermes repo so that we can test Hermes against iOS other than android.
## Changelog:
[Internal][Added] - Add possibility to download Hermes from a specific commit
Reviewed By: cortinico
Differential Revision: D44460479
fbshipit-source-id: 89c196aa7c38533e4904444f7f17eb3236fc6356
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36677
## Changelog:
[Internal] - Don't cache UIManager type inside the Event data structure
A follow up to https://github.com/facebook/react-native/pull/36659
It's redundant, and it's good to have fewer "sources of truth" and keep the notion of UIManagerType separate from Event data structures.
Reviewed By: javache
Differential Revision: D44453812
fbshipit-source-id: 4efc0bb115bb4750e27afb2390afc9736ae67469
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36682
## Changelog:
[Internal][Fix] - Fix hashing function in event name mapping in PerformanceEntryReporter
A textbook mistake, when mapping event names via the constant lookup table, only the first 8 characters were effectively taken into account, thus mixing names of some events.
Reviewed By: rubennorte
Differential Revision: D44462195
fbshipit-source-id: 273891d92251014661af731618d8a549627b2983
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36669
The test: Route all TurboModules in Fb4a through the interop layer.
So now, instead of using the C++ codegen for method dispatch, TurboModules will instead be using JavaInteropTurboModule, which uses the ReactMethod annotations for method dispatch.
MobileConfig actualization diff: D44405316.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D44405336
fbshipit-source-id: 3b00028e26cdcd229e64630eef73409a3264636a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36667
## Context
TurboModuleManagerDelegate exposes two methods that create TurboModules:
- TurboModule getModule()
- CxxModuleWrapper getLegacyCxxModule()
## Problem
TurboModuleManagerDelegate.getLegacyCxxModule() is redundant: getModule() could just return all the modules that getLegacyCxxModule() returns: getLegacyCxxModule returns modules that implement TurboModule.
## Changes
So, let's deprecate getLegacyCxxModule(). This will simplify the implementation of TurboModuleManager.
Changelog: [Android][Deprecated] - Deprecate TurboModuleManager.getLegacyCxxModule
Reviewed By: cortinico
Differential Revision: D44407802
fbshipit-source-id: 88a6cf6597db76d8a74fd777d68ccf4f43aa6811
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36629
The scope of TurboModuleManager is increasing:
- Eventually, it'll be capable of creating interop NativeModules (i.e: NativeModules that don't implement TurboModule).
So, instead of creating duplicate methods for NativeModules on the TurboModuleManager, this diff changes the APIs of TurboModuleManager to work with the NativeModule interface.
Thoughts?
## Questions
**Question:** Is this a breaking change for open source?
- Technically, yes. This diff changes the public interface of TurboModuleManager.
**Question:** How large of a thrash will this cause for open source apps?
- The thrash should be minimal. People in open source shouldn't be creating their own TurboModuleManager. They also shouldn't be directly accessing the TurboModuleManager object either.
**Question:** Is this change safe?
- Yeah. All the code that calls into TurboModuleRegistry converts TurboModules it returns into NativeModules.
**Question:** Is this change move us in the right direction?
- Long term, the TurboModule system will support legacy modules as well as TurboModules.
- I think it makes a lot of sense to have one Java-facing registry: after all, Java will just treat these NativeModules/TurboModules as regular Java objects, and call public methods on them. It doesn't care if the module is TurboModule-compatible or not.
- As for the TurboModuleRegistry abstraction, I think we should eventually rename this to NativeModuleRegistry after we delete the current NativeModuleRegistry.
- Still thinking about this though. I will leave this diff in review to welcome comments.
Changelog: [Android][Deprecated] - Deprecate TurboModuleRegistry.getModule(), getModules(), hasModule(),
Reviewed By: mdvacca
Differential Revision: D43801531
fbshipit-source-id: 4af7cbc2e2dc7c1d664acbd38c83aa93aae23c9f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36628
The legacy NativeModule system supports integer and float in NativeModule method arguments and returns. This diff extends the TurboModule system for the same functionality. T
his is necessary because the TurboModule system will now need to dispatch method calls to legacy NativeModules.
NOTE: We can't actually test these changes until we run interop modules.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D44000389
fbshipit-source-id: 92282d582a0f98fcb88d83e460d4860a64fe1117
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36625
## Context
Previously, jsRepresentation would only cache the **HostFunctions** returned from TurboModule::createHostFunction().
## Changes
This diff replaces TurboModule::createHostFunction() with TurboModule::create().
Now, jsRepresentation will cache **all** the **properties** returned from TurboModule::create().
## Motivation
For interop modules, constants will be exported as properties on the TurboModule HostObject. This diff allows those constants (which are non HostFunctions) to be cached.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D44253229
fbshipit-source-id: d3dd042f4ccb6c076b83503f3712e4d1609388ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36626
In Bridgeless mode, With the TurboModule interop layer, the TurboModule system will need to customize the nativeModuleProxy global.
This customization would be much easier if the nativeModuleProxy global were installed by the TurboModule system (and not the Bridgeless core).
So, this diff moves nativeModuleProxy installation into the TurboModule system.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D43993197
fbshipit-source-id: 9361340c02e2d82c4e5f373f234f41dc9d72cbe4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36679
We expose a variant of `HermesExecutor.java` which allows you to set a custom max heap size. This variant also sets the `AllocInYoung/RevertToYGAtTTI`, which should never really be used without a matching call to `HermesInternal.ttiReached()`, which is not documented.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D44457318
fbshipit-source-id: e91b377cbc0ac596cfbe7d1178e2657b868c1067
Summary:
The `Renderer` directory is supposed to be only for files synced from the React repo. This moves the `public` directory that was added to it recently to the `ReactNative` directory.
Changelog: [internal]
bypass-github-export-checks
Reviewed By: sammy-SC
Differential Revision: D44421951
fbshipit-source-id: d098970b80cd467b5c772c3ae91ce716be373484
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36659
## Changelog:
[Android][Fixed] - Fix dispatching into incorrect UIManager type when event's target is a root view
There is a function, called [ViewUtil.getUIManagerType](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/uimanager/common/ViewUtil.java#L22), which infers whether we are using the new or old architecture, given a View tag ID, with the assumption being that all New Architecture tags are even (and therefore, we are in the New Architecture iff the view tag is even). See [here for more context](https://github.com/facebook/react/pull/12587/files).
This function was used to find out which type of event dispatcher to dispatch to, when going down the chain of event dispatching function calls on Android.
The problem is, that there may be cases, when this odd/even assumption breaks, in particular when the target view ID is equal to `1`, meaning that it's a root view ID and there is nothing else mounted there yet.
It's very rare that this happens in practice, but still is possible that user interacts with the screen before anything is mounted there (or if there is nothing mounted there by design).
Reviewed By: javache
Differential Revision: D44421739
fbshipit-source-id: fd5ba3c882f6c7d3c9543ebc2ec30ba000f7ca4f
Summary:
Currently we have a tool (rnx-kit/rn-changelog-generator) that extracts changelog messages from our commit history to generate the changelog for a React Native release.
In hopes of standardizing to one place where changelog validation occurs -- I've moved this logic to the package rnx-kit/rn-changelog-generator such that if the formatting ever changes, the changelog parsing is also updated.
Changelog: [Internal] - Updating danger to use logic in rnx-kit/rn-changelog-generator for changelog validation.
Pull Request resolved: https://github.com/facebook/react-native/pull/36507
Test Plan: Tried `require`-ing the package and on a changelog message. I'm not sure exactly how to test a dangerfile -- IIRC it has to run off `main`
Reviewed By: cortinico, cipolleschi
Differential Revision: D44183479
Pulled By: lunaleaps
fbshipit-source-id: f65440f7b66a048f961d4698d78210c74e276452
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36645
This broke while changing the AnimatedInterpolation back in D40571873 and D40632443, as I assumed the native side would be able to correctly handle values such as '1rad'. However these were being sent over as strings, and were thus using the string interpolation path, which does not work here.
Instead, handle both `deg` and `rad` explicitly when generating the config in JS.
Resolves issue https://github.com/facebook/react-native/issues/36608
Changelog: [General][Fixed] Resolves Animated.Value.interpolate results in NaN when output is in radians
Reviewed By: yungsters
Differential Revision: D44406034
fbshipit-source-id: fe0f3df16f2b8ec6c31f9359e4706cacc72b9951
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36662
For VR, JSPointerDispatcher skips calculating the delta of hit targets (which happens in onMove) on the frame in which the active controller is switched because the motion event is a DOWN event, not a MOVE event in that specific frame.
This diff fixes the issue by just calling onMove in addition to onDown for DOWN motion events. Unfortunately we do not have separate pointer IDs for each controller.
This won't change the behavior for non-hoverable pointers. For hoverable pointers, it will dispatch an extra pointer_enter if the hit path has changed between the last move event and the down event.
Changelog:
[Internal][Fixed] - Trigger pointer leave when active controller switched
Reviewed By: lunaleaps, javache
Differential Revision: D44377324
fbshipit-source-id: 9f668e64f486b9a12ab36563ec2b7cf93f208a54
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36648
Changelog: [Internal]
Blocker for https://github.com/facebook/react-native/pull/36623. The `test-ios` job in CI was misconfigured following the monorepo migration — and this becomes load-bearing with the incoming version of React Native CLI.
- Update `objc-test.sh` to run in `packages/rn-tester`, and exclude tests under `/IntegrationTests` which are outside of a Metro project directory.
- **This is temporary** — a task has been created to move/split up/otherwise restore tests in `IntegrationTests`, which cipolleschi is following up (thanks!).
- Also fix `yarn start` script in `packages/rn-tester`.
Reviewed By: cipolleschi
Differential Revision: D44416533
fbshipit-source-id: 59c5b743d9d8fda206a12e37d94324ed9bfd703e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36568
Changelog: [Internal]
Okay, so before the monorepo migration we had to use two scripts separately:
1. Bumping every package with `npm run bump-all-updated-packages`
2. Aligning other packages versions with `npm run align-package-versions`
The reason for it is that *before the monorepo* in a release branch cutoff process we had a step, which was removing `workspaces` keyword from `react-native` package. Without this keyword all new versions of packages will be resolved from npm (where they will be not available yet, because we have to publish them prior to it)
This is not the case for our current setup, and we can actually bump packages versions and they will be resolved as a workspaces successfully
Reviewed By: cortinico, cipolleschi
Differential Revision: D44261057
fbshipit-source-id: 31c2157be2d3b33bc073651d6045efcef2e8f5c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36575
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
D23670779 addedd a previous mechanism to add spans for measurement caching, like we needed to do as part of this change. It is called in more specific cases (e.g. when there is a text hint but no text), but it edits the live EditText spannable instead of the cache copy, and does not handle nested text at all.
We are already adding spans back to the input after this, behind everything else, and can replace it with the code we have been adding.
Changelog:
[Android][Fixed] - Mimimize EditText Spans 9/9: Remove `addSpansForMeasurement()`
Reviewed By: javache
Differential Revision: D44298159
fbshipit-source-id: 1af44a39de7550b7e66e45db9ebc3523ae9ff002
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36634
X-link: https://github.com/facebook/metro/pull/957
The existential type `*` has been deprecated and just an alias for `any` since version 0.163. Codemod usage of it to `any`.
This helps with diff D44276187, which makes it always an error to use `*`.
Changelog: [internal]
Reviewed By: pieterv, SamChou19815
Differential Revision: D44358809
fbshipit-source-id: c6bb55430edd086958e16989c60bc2a0a131a3fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36577
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change allows us to strip CustomStyleSpan. We already set all but `fontVariant` on the underlying EditText, so we just need to route that through as well.
Note that because this span is non-parcelable, it is seemingly not subject to the buggy behavior on Samsung devices of infinitely cloning the spans, but non-parcelable spans have different issues on the devices (they disappear), so moving `fontVariant` to the top-level makes sense here.
Changelog:
[Android][Fixed] - Minimize EditText Spans 8/N: CustomStyleSpan
Reviewed By: javache
Differential Revision: D44297384
fbshipit-source-id: ed4c000e961dd456a2a8f4397e27c23a87defb6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36576
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change addresses some minor CR feedback and removes the temporary list of spans in favor of applying them directly.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D44295190
fbshipit-source-id: bd784e2c514301d45d0bacd8ee6de5c512fc565c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36548
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change lets us set `letterSpacing` on the EditText instead of using our custom span.
Changelog:
[Android][Fixed] - Minimize EditText Spans 6/N: letterSpacing
Reviewed By: rshest
Differential Revision: D44240777
fbshipit-source-id: 9bd10c3261257037d8cacf37971011aaa94d1a77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36544
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change makes us apply strikethrough and underline as paint flags to the underlying EditText, instead of just the spans. We then opt ReactUnderlineSpan and ReactStrikethroughSpan into being strippable.
This does actually create visual behavior changes, where child text will inherit any underline or strikethrough of the root EditText (including if the child specifies `textDecorationLine: "none"`. The new behavior is consistent with both iOS and web though, so it seems like more of a bugfix than a regression.
Changelog:
[Android][Fixed] - Minimize Spans 5/N: Strikethrough and Underline
Reviewed By: rshest
Differential Revision: D44240778
fbshipit-source-id: d564dfc0121057a5e3b09bb71b8f5662e28be17e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36545
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This adds ReactForegroundColorSpan to the list of spans eligible to be stripped.
Changelog:
[Android][Fixed] - Minimize Spans 4/N: ReactForegroundColorSpan
Reviewed By: javache
Differential Revision: D44240780
fbshipit-source-id: d86939cc2d7ed9116a4167026c7d48928fc51757
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36547
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This adds `ReactBackgroundColorSpan` to the list of spans eligible to be stripped.
Changelog:
[Android][Fixed] - Minimize Spans 3/N: ReactBackgroundColorSpan
Reviewed By: javache
Differential Revision: D44240782
fbshipit-source-id: 2ded1a1687a41cf6d5f83e89ffadd2d932089969
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36546
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change generalizes `stripAttributeEquivalentSpans()` to allow plugging in different spans.
Changelog:
[Internal]
Reviewed By: rshest
Differential Revision: D44240781
fbshipit-source-id: 89005266020f216368e9ad9ce382699bd8db85a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36543
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
We cache the backing EditText span on text change to later measure. To measure outside of a TextInput we need to restore any spans we removed. Spans may overlap, so base attributes should be behind everything else.
The logic here for dealing with precedence is incorrect, and we should instead accomplish this by twiddling with the `SPAN_PRIORITY` bits.
Changelog:
[Android][Fixed] - Minimize Spans 1/N: Fix precedence
Reviewed By: javache
Differential Revision: D44240779
fbshipit-source-id: f731b353587888faad946b8cf1e868095cdeced3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36621
After D44302691 enabled textShadow, there was a subtle 1px shadow on any new text which I did't spot, but screenshot tests did (after commit which is non-ideal, but there is more work to make these land blocking).
This is because unlike `ReactBaseTextShadowNode` in paper which defaults to a radius of zero (no shadow), `TextAttributes` in Fabric defaults to a radius of 1px. Just previously never displayed.
Without shadow:
https://pxl.cl/2z2wX
With shadow:
https://pxl.cl/2z2x0
This changes the default to zero, which will cause us to skip adding the span, and matches previous behavior in Paper.
I double-checked the other props are defaulted the same way between `BaseTextShadowNode` (Paper) and `TextAttributes` (Fabric).
Changelog:
[Android][Fixed] - Fix default shadow radius in TextAttributeProps
Reviewed By: javache
Differential Revision: D44364446
fbshipit-source-id: d207367608291048001403d292f881c0842113f9
