Summary:
Whenever we remove a link in some text we do not properly update the accessibility delegate to respond to this change. As a result we still think that there are nodes to access around the spans
Changelog: [Android][Fixed] - Fix text link accessibility on state update removal
Reviewed By: NickGerleman, mdvacca
Differential Revision: D69551906
fbshipit-source-id: f43fcf72219e76d2d0bbb29d31ab219d73413671
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49377
ReactAccessibilityDelegate exists to handle much of the accessibility tasks in the various Views in RN. There is quite a bit of text specific logic, mostly related to virtual views and nested links within a TextView.
I decided to subclass this into a TextView-specific version because I need this delegate to reference TextView or ReactClickableSpan, which live under `react/views` while ReactAccessibilityDelegate live under `react/uimanager`. The former depends on the latter, so making the latter depend on the former would for a dependency cycle that would break builds. I thought about making a separate package for this but both `react/views` and `react/uimanager` need to include ReactAccessibilityDelegate so we would still have a cycle.
mAccessibilityLinks is only set on ReactTextViewManager, so this is purely a text thing. Subclassing is not the most ideal as it extends the inheritance chain some more but I do not see a better option.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D69499115
fbshipit-source-id: 1720d20bb56ba1e1b5bd114d32bc70e80e3b4558
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49581
I need to be able to find a View with a specific nativeId as part of my implementation of accessibility ordered children. This already exists in Android in `ReactFindViewUtil.kt`.
Not much to this implementation. Recursive tree searching. I do not think perf is a big deal here but if we want to optimize this we could implement some nativeId registry and try and get the UIView * from that at the expense of storing that map somewhere.
Changelog: [Internal]
Reviewed By: vincentriemer
Differential Revision: D69868430
fbshipit-source-id: b3648a8dca351bed50534cac2144d7e8ea0a207f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49590
This feature flag was used to validate a fix for handling of events during
gesture on pressable. It can now be removed as the flag has been set to true for several
internal app (Twilight among others) for several months.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D69983235
fbshipit-source-id: 89b96b3e4c98ae258982341f56ddc13aa2fe51bd
Summary:
Opening this as a separate PR, since I'm not sure if I'm missing something, or if there's any intention behind this.
`react-native/metro-babel-transformer` is used by `react-native/metro-config` and is referenced in code there and as a dependency there. It's also sometimes mentioned as package for community CLI users to install directly. However, there's seemingly no reason `react-native/metro-babel-transformer` needs to depend on it, or any code that relies on it directly.
## Changelog:
[INTERNAL] [CHANGED] - Remove extraneous `react-native/metro-babel-transformer` dependency from community-cli-plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/49558
Test Plan: - n/a
Reviewed By: robhogan
Differential Revision: D69926109
Pulled By: huntie
fbshipit-source-id: b89b54890248de4954e5c0ce4afe3a5cb5bfa2c1
Summary:
Update androidx app compat to the latest version.
This is needed as part of https://github.com/facebook/react-native/pull/49486 to have access to `fullyDrawnReporter`.
## Changelog:
[ANDROID] [CHANGED] - Update androidx app compat to 1.7.0
Pull Request resolved: https://github.com/facebook/react-native/pull/49594
Test Plan: Tested in RN tester that it builds fine and works properly.
Reviewed By: Abbondanzo
Differential Revision: D69988202
Pulled By: cortinico
fbshipit-source-id: 0329aa84a76327db535ddba8acf059ebbf1dbdfc
Summary:
This package does not seem to be referenced by anything but the tests in `packages/dev-middleware`, so seems like a pretty straightforward change to drop it from `dependencies`.
It only seems to be referenced in `packages/dev-middleware/src/__tests__/ServerUtils.js`
## Changelog:
[INTERNAL] [CHANGED] - Remove selfsigned from dev-middleware dependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/49556
Test Plan: - n/a
Reviewed By: cipolleschi
Differential Revision: D69925928
Pulled By: huntie
fbshipit-source-id: bba41f81dba054505ebf196ad37c7a718a6b16da
Summary:
While `readline` is referenced in `packages/community-cli-plugin/src/commands/start/attachKeyHandlers.js`, this references the `node:readline` module by default. The extra package seems to have been installed and included accidentally, as the `attachKeyHandlers` file uses an export from `node:readline` that's never been present in `npm:readline`.
Since the name matches but Node.js will always prefer built-in/code modules, this dependency is dangling and can never be reached, since it's name is shadowed (as also stated in their readme). This can be reproduced by comparing `require('readline')` and `require('../../node_modules/readline')` in `packages/community-cli-plugin`. The flow types also confirm this.
This overall seems highly safe to drop.
## Changelog:
[INTERNAL] [CHANGED] - Remove shadowed and unused readline npm package from community-cli-plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/49557
Test Plan:
Prior to changes applied:
```sh
$ node -e 'console.log(require("readline") === require("node:readline"))'
true
```
Reviewed By: cipolleschi
Differential Revision: D69925999
Pulled By: huntie
fbshipit-source-id: 802fdaa396630b44d5aacefeb9c2473fb53d167e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49589
We should not be attempting to compile anything related to the annotation
processor in either Kotlin or Java.
This excludes those folders from the Kotlin compilation task as the
CI is currently red because of it.
Changelog:
[Internal] [Changed] -
Reviewed By: huntie
Differential Revision: D69981620
fbshipit-source-id: 7e2d534023ab1c00e5aadf8546440a4cc4c01ec0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49572
Changelog: [internal]
This adds a test to verify the behavior of 2 feature flags: synchronous state updates and UI consistency.
Reviewed By: javache
Differential Revision: D69932313
fbshipit-source-id: 341cfff3fa533503a293f6ccd0282442ba63d430
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49586
Reverting https://github.com/facebook/react-native/pull/49413 as it was causing a crash with assertion failure in ReactViewGroup.addViewWithSubviewClippingEnabled()
Changelog:
[INTERNAL] revert Kotlin conversion due to crash
Reviewed By: sbuggay
Differential Revision: D69953848
fbshipit-source-id: b438fb928a4849f3dbad6a9d59d0f48449035fd6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49570
This diff creates a initial version of the annotation processor to output the list of types that are annotated with LegacyArchitecture
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D69929875
fbshipit-source-id: 90a8d299f4667ab8d103c061d287991dbdb291df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49569
In this diff I'm annotating a subset of bridge classes with LegacyArchitecture
The goal is to test the annotation processor in next diffs
changelog: [internal] internal
Reviewed By: cortinico, Abbondanzo
Differential Revision: D69929878
fbshipit-source-id: 8be4d010f6519617d334da361983dce0fa66e3b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49568
The goal of this annotation processor is to generate a file with all the types that belong to Legacy Architecture of React Native
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D69929876
fbshipit-source-id: c21bf1a868258b20be91721006d7fc8fa85adcd1
Summary:
This upstreams a change from [RNTV](https://github.com/react-native-tvos/react-native-tvos/) to allow the glog prepare script to work on both iOS and tvOS.
## Changelog:
[Internal][Changed] make iOS glog script compatible with tvOS
Pull Request resolved: https://github.com/facebook/react-native/pull/49539
Test Plan:
- This change works well on the TV repo
- CI should pass, and iOS compilation and operation should be unchanged
Reviewed By: cortinico
Differential Revision: D69928586
Pulled By: cipolleschi
fbshipit-source-id: b5fec438151e659e98834a83effbc7e166df6aa5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49552
Changelog:
[General][Internal] - expand debugger events to have DebuggerSessionIDs
Also moved the handling of these to a shared function
Reviewed By: huntie
Differential Revision: D69917817
fbshipit-source-id: 2374ac5b5dc0040b0e15028ab89fbe78026bc296
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49515
changelog: [internal]
_currentSafeAreaInsets should be initialised as part of `startObservingSafeArea` to make sure it is set before accessed.
Even though, right now _currentSafeAreaInsets is always set before it is read because notification RCTUserInterfaceStyleDidChangeNotification fires eagerly, it might change in the future and introduce a bug.
Reviewed By: lenaic
Differential Revision: D69846681
fbshipit-source-id: f8be8a53e82020112abd170b9f20429bf7ba7011
Summary:
When building `react-native-windows` our code analysis tools complained about an implicit `double` to `PointerIdentifier` in NativeDOM.cpp.
This PR adds an explicit cast.
Temporary downstream patch: https://github.com/microsoft/react-native-windows/commit/5957d0af6944d64513cead28186dfbcc74bbfea0
## Changelog:
[GENERAL] [FIXED] - Add explicit casts for pointerIds for PointerEvents in NativeDOM
Pull Request resolved: https://github.com/facebook/react-native/pull/48578
Test Plan: React Native Windows builds with this change and no more warnings.
Reviewed By: rubennorte
Differential Revision: D69920656
Pulled By: cipolleschi
fbshipit-source-id: 1d81f1fbfd91fadfb676d3e65c3c9cb729c1d3dd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49553
The new React-renderercss pod is an header only pod. These are not allowed by Cocoapods, because it will not materialize the framework when building with then turned on.
the solution is to just add an empty source file to frorce cocoapods to materialize the .framework file and solve the dependency graph properly.
## Changelog:
[Internal] - Add dummy file to React-renderercss
Reviewed By: huntie
Differential Revision: D69920318
fbshipit-source-id: e5cc092a480f7c86eeb295ed966f85b6f55fdc54
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49554
For some reason, this diff completely breaks the linker on iOS.
I tried to look for a fix forward, but unsuccessfully.
I'm reverting this diff to get CI green again, but this requires more investigation.
## Changelog:
[Internal] - Revert D69805065
Reviewed By: sammy-SC, huntie
Differential Revision: D69920338
fbshipit-source-id: 8e1d34b5314d8ead51c127208ae2d2250f7d3724
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49522
While testing the script, sometime I obtained undesired results because I was passing the wrong values for the arguments.
This change add a simple validation function to inform the user when the arguments that are passed are not valid.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D69851416
fbshipit-source-id: c378a3ca5db942cca5178274204a0d01d1eefdf7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49523
There was a typo when checking the configuration. The default parameter is `all`, not `All`.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D69851429
fbshipit-source-id: 7f16f5f89c90824ceb57f9980bc38a31be33ccfe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49524
If there is already an XCFramework in the current location. xcodebuild fails to create and override the xcframework.
This change allows us to override an old xcframework and to iterate more quickly.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D69851428
fbshipit-source-id: 723b3035cec008e2bd177da4f960f2bb085ff493
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49514
This attemps to enable Config Caching on CI. I'm curious to see how much time this is going to save.
There might be some problems with nigthlies so I want to make sure this is running for some days before the branch cut.
Changelog:
[Internal] [Changed] -
Reviewed By: NickGerleman
Differential Revision: D69846848
fbshipit-source-id: 0d5c292e65a6107df62f6494a1aae9abd0e8b6cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49535
changelog: [internal]
Add a unit test to cover scenario where ScrollView's parent has a transform
Reviewed By: NickGerleman
Differential Revision: D69860855
fbshipit-source-id: 1b64665c5b15ad2e5e068d4c6d56f9694ac7cf03
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49546
Right now we rely on the ViewConfig processor to fire an invariant if the values are incorrect. We really don't want to redbox in the future on invalid properties, and this won't be around for the native CSS parsing path.
This code has some problems, like... radian parsing allowing potential out-of-bounds reads, firing a native assert for valid 9 digit matrices, or the layers in conjunction treating `0.5r.degoggos00` as a valid way to say 0.5 radians. Wheeee!
This change mostly just ports over the checks from `processTransform` to validate parameters before we use them, treating the whole transform list as invalid if any part of it is broken. I moved radian and percentage parsing the the CSS data type parsers as well.
I avoided changing props structures again here.
Changelog:
[General][Changed] - Add validation to Fabric parsing for transform options
Reviewed By: javache
Differential Revision: D69823064
fbshipit-source-id: 87c6da448a4b55e0507382b98aabd62ce3e4587f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49545
During tokenization we use 32 bit integers to store the digits before and after a decimal place.
Code interpolating strings may produce float strings with the part after digits being greater than max int, in which case we encounter integer overflow caught by UBSAN.
I was curious how libc functions for decoding floats handled this, and musl libc goes really out there, storing each intermediate digit in an array of 128 or more digits, and later using `long double`, in a shockingly complicated function. https://github.com/kraj/musl/blob/1880359b54ff7dd9f5016002bfdae4b136007dde/src/internal/floatscan.c#L63
We... probably don't need to go that far, but storing these intermediate digits as doubles should be precise enough and allow large enough values in the vast majority of cases.
Changelog: [Internal]
Reviewed By: sammy-SC, jorge-cab
Differential Revision: D69881560
fbshipit-source-id: b2158ce2c5d85157426cea9850c7f62c2eee5611
Joe Vilches
Nicola Corti
Mateo Guzmán
Jack Pope
Henry Garant
Dawid Małecki
Phil Pluckthun
Janic Duplessis
Samat Osmonov
Jakub Piasecki
Rubén Norte
Vitali Zaidman
Alan Lee
David Vacca
Douglas Lowder
Samuel Susla
Jon Thysell
Riccardo Cipolleschi
Fabrizio Cucci
Nick Gerleman