Summary: [RN][iOS] Changelog: [Internal][Fix] Minor fix: Don't display a legacy surface from Logbox if Bridge is invalid
Reviewed By: RSNara
Differential Revision: D36268234
fbshipit-source-id: 227f465fb1fc2953b5d6813485ed6750b1d3dea3
Summary:
Changelog: [Internal][iOS] Fix AppState in Bridgeless mode by removing guard for bridge, since it doesn't use bridge
AppState doesn't use bridge because RCTAppState subclasses RCTEventEmitter, which calls `_callableJSModules invokeModule` in both Bridge and Bridgeless mode to send events to JS.
Reviewed By: fkgozali
Differential Revision: D35988515
fbshipit-source-id: fb19f0f2df5b270f0ef57637930f94686e39a9a1
Summary:
This would fix test errors caused by including <string> in non-C++ compatible files.
Changelog:
[General][Changed] - Remove usage of std::string in EarlyJsErrorHandler.
Reviewed By: RSNara
Differential Revision: D35645334
fbshipit-source-id: 7f04d2c66d53dc1eef63367de1a64ed9273898f5
Summary:
Changelog:
[iOS][Fixed] - Expose the extraData dict attached to JavaScript errors to the native ExceptionManager on iOS, similar to Android
Attaching the `extraData` dict to JavaScript crash reports is something that was done for Android only in 2019 (D16133080 (https://github.com/facebook/react-native/commit/3a825c036065783aae6fb734028f986dbead80d7)), and somehow we never really got around to adding it in iOS. This diff finally adds the capability to iOS as well. `extraData` can be used to attach various bits of data to a crash report for better debugging and categorization. As with the Android implementation, `extraData` is not attached if the `reportException` API is not used.
Reviewed By: dmitryrykun
Differential Revision: D35743658
fbshipit-source-id: de4060cb6e514db1d85907441a8962f98e9b8392
Summary:
`hotkeysEnabled` property is added to `RCTDevMenu` which allows enabling/disabling hotkeys that triggers developer menu popup
Changelog:
[iOS][Added] - `hotkeysEnabled` property is added to `RCTDevMenu` which allows enabling/disabling hotkeys that triggers developer menu popup
Reviewed By: arhelmus
Differential Revision: D35777883
fbshipit-source-id: a7435358701bedb54e33198724180eb1c27248b8
Summary:
Changelog: [internal]
we have an issue where the moduleRegistry that the TM uses is released, adding this log to check if it's bc the bridge was released
Reviewed By: RSNara
Differential Revision: D35420922
fbshipit-source-id: 93c206b5afefeac3121df148940d9658736cb9d2
Summary:
changelog: [internal]
this never fired, so it's not the cause of the nil moduleRegistry issue
Reviewed By: christophpurrer
Differential Revision: D35419873
fbshipit-source-id: 45693d3aa97d9efed2fe5085c281b57f1629764d
Summary:
Now that the PFH node has been renamed this updates the pfh label.
Produced via `xbgs -l -e '"pfh:ReactNative_CommonInfrastructurePlaceholde"' | xargs sed -i 's/"pfh:ReactNative_CommonInfrastructurePlaceholde"/"pfh:ReactNative_CommonInfrastructurePlaceholder"/'`
Reviewed By: jkeljo
Differential Revision: D35374087
fbshipit-source-id: 61590f69de5a69ec3b8a0478f6dd43409de3c70b
Summary:
While it would be better to be able to do all of the ownership metadata at the Buck macro level, that proved to be more work than expected.
This diff adds the corresponding pfh label to all targets in `xplat/js/react-native-github` that have a Supermodule label. Once the migration is complete the Supermodules labels will be able to be removed.
Reviewed By: cortinico
Differential Revision: D35221544
fbshipit-source-id: d87d5e266dfb5e6ee087251dc34dff5db299bbaf
Summary:
Changelog: [iOS][Internal] Refactor: Migrate Logbox surface initialization to Fabric when available, in Bridge and Bridgeless modes
# Why
This diff main purpose is to add `RCTErrorNewArchitectureValidation(RCTNotAllowedInAppWideFabric)` in `RCTSurface`, to ensure Paper surfaces are never created in FBiOS.
# The Situation
Before this diff, in Bridged Fabric, `[RCTLogbox show]` initializes a Paper `RCTSurface`, [using `[RCTLogBoxView initWithWindow]`](https://github.com/facebook/react-native/blob/main/React/CoreModules/RCTLogBoxView.mm#L46))
In this diff, in Bridged and Bridgeless Fabric, `[RCTLogbox show]` initializes a Fabric `RCTFabricSurface`.
Before this diff, in Bridgeless Fabric, RCTLogBox posts a "CreateLogBoxSurface" notification to RCTInstance.
In this diff, the notification hack is replaced by the same `RCTFabricSurface` initialization above.
Behavior is the same.
Reviewed By: RSNara
Differential Revision: D35177311
fbshipit-source-id: 6de418af8a01f914c9a806bb8d74915015f9087a
Summary:
In short, if an RCTEventDispatcher observer sends an event on the same thread that the observer was initially on, there will be a deadlock due to `sendEvent` already having the lock active on the `_observers` NSHashTable. An example where this occurred was when we had react-native-gesture-handler trigger an animated event, which then triggered an event on the underlying component being animated as a result of it being an observer on the animation event. Since this all occurred on the main thread, we ended up with a deadlock and the app froze.
To prevent this scenario, I used a `NSRecursiveLock` for _observersLock to be able to dispatch events on the same thread from observers.
joebernard
## 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] [Fix] - Prevent deadlock when dispatching events from observers on the same thread.
Pull Request resolved: https://github.com/facebook/react-native/pull/33490
Test Plan:
Not sure if there are any tests present for sending events with RCTEventDispatcher already in place, but In regular app usage this solution has proved to be a viable and stable option so far and has prevented the deadlock from occurring.
This would still be thread-safe since we are now allowing the event to be sent through observers on the same thread the initial event was dispatched on. The only issue I could see here is the behavior of sending an event could be changed.
Reviewed By: RSNara
Differential Revision: D35118752
Pulled By: charlesbdudley
fbshipit-source-id: 7e93a8d49841e001b235a437ccca1e072dcc7ab1
Summary:
If an RN app is embedded in a Mac Catalyst app that uses the UIWindowScene API to manage multiple windows, LogBox would fail to render because it didn't know which UIWindowScene to render to. This diff fixes that situation by ensuring that the LogBox window gets rendered in the key window's scene.
Changelog:
[iOS][Fixed] - Update iOS LogBox to render its UIWindow with the key window's UIWindowScene
Reviewed By: appden
Differential Revision: D35027831
fbshipit-source-id: e0df5865f95323b03d08d6b1fb3ec912aa9a9167
Summary:
Changelog: [Internal]
this doesn't really make any sense, first of all CGFloat is a primitive data type so comparing it against nil only will return true if it's 0. but that won't catch cases where CGFloat is uninitialized bc it will be holding junk in memory.
the error checking of the value is already handled in the accessibility manager, so just remove it here.
Reviewed By: p-sun
Differential Revision: D34909365
fbshipit-source-id: 483f9c100433f8533edd784622523c5469c616c2
Summary:
Changelog: [Internal]
for the last 6 months or so, we've been getting this task where the moduleRegistry in RCTDeviceInfo is nil. in this change, i add some logs to see what might be setting this to nil.
in all honestly, i don't really think this is happening, but it would be good to verify.
Reviewed By: sshic
Differential Revision: D34908902
fbshipit-source-id: d375285467a87453605ba0fecfc124bc3bff6e63
Summary:
This PR adds a `dismissActionSheet` method to `ActionSheetIOS` in order to allow dismissing an ActionSheet programmatically. This is especially useful in apps where a user has the ability to open an ActionSheet and then open a push notification that will redirect them to another screen which usually leads to scenarios where the presented ActionSheet has no relation with the current screen.
#### TODO
- [ ] Submit react-native-website PR updating ActionSheetIOS documentation.
## Changelog
[iOS] [Added] - Add dismissActionSheet method to ActionSheetIOS
Pull Request resolved: https://github.com/facebook/react-native/pull/33189
Test Plan:
1. Open the RNTester app and navigate to the ActionSheetIOS page
2. Test `dismissActionSheet` through the `Show Action Sheet and automatically dismiss it` example
https://user-images.githubusercontent.com/11707729/155867546-c6770a49-9b09-45e3-a6b1-4f7645d67dbf.mov
Reviewed By: lunaleaps
Differential Revision: D34518952
Pulled By: cortinico
fbshipit-source-id: 912a9b83ee078f791b42efddf5abb7e1cd09d520
Summary:
alternative solution for https://github.com/facebook/react-native/issues/33379
> when `use_frameworks!` is on, there are errors like:
> ```
> 'FBReactNativeSpec/FBReactNativeSpec.h' file not found
> #import <FBReactNativeSpec/FBReactNativeSpec.h>
> ```
> this error may come from from https://github.com/facebook/react-native/commit/f7e4c07c84b6 regression.
>
> when `use_frameworks!` is on, xcode will search headers from framework directories, the correct imports would be `#import <React_Codegen/FBReactNativeSpec/FBReactNativeSpec.h>` (xcode will transform dash to underscore, so it is `React_Codegen` but not `React-Codegen`). in the other hand, when `use_frameworks!` is off, the correct import is `#import <React-Codegen/FBReactNativeSpec/FBReactNativeSpec.h>`.
>
>
> this fix is specific for old architecture (fabric is off).
>
> when fabric is on, there are other errors from duplicated headers when copying to build folder. [the reason is that framework build would try to flatten headers](https://mkonrad.net/2015/03/29/xcode-static-libraries-preserving-header-directory-structure.html). we have `primitives.h` in different folders and they would be flattened into `React_Fabric.framework/Headers`. to be honest, i don't know how to deal with the problem in the meantime, maybe subspecs are not enough, we should separate them from subspecs to dedicated podspecs so that we can have these targets as different frameworks.
in this alternative fix, i try to add `React-Codegen/React_Codegen.framework/Headers` into header search paths and make original `#import <FBReactNativeSpec/FBReactNativeSpec.h>` reachable.
[this change](https://github.com/facebook/react-native/commit/7a0398c331f22abc619a64b444ec7153357b0a30) in the pr is just a workaround to solve breaking in latest main branch and this is not important to the `use_frameworks!` fix at all. this breaking was coming from https://github.com/facebook/react-native/commit/180495159517dc0bfa103621e5ff62fc04cb3c8b.
## Changelog
[iOS] [Fixed] - Fix iOS build error when Podfile `use_frameworks!` is on and Fabric is off
Pull Request resolved: https://github.com/facebook/react-native/pull/33409
Test Plan:
verify with rn-tester
1. change `fabric_enabled` to false in `packages/rn-tester/Podfile`
2. `USE_FRAMEWORKS=1 pod install`
3. build rn-tester in xcode
Reviewed By: dmitryrykun
Differential Revision: D34817041
Pulled By: cortinico
fbshipit-source-id: 4d1a610e99a807793eb3f64461e0d735c0a9ca9c
Summary:
Hoop up EarlyJsErrorHandler so we could pass js error data to object-c to report.
Changelog:
[iOS][Chagned] - Add function to report early js errors
Reviewed By: RSNara
Differential Revision: D34096343
fbshipit-source-id: fdbc6ea5d1f3cc6ab55fcd22b48bbe8fb1f1ca8f
Summary:
In iOS, the native LogBox that gets rendered for JS errors/warnings is statically sized once and bases that size off of the entire screen's size. This causes issues when being run in a Mac Catalyst app since 1) the sizing is not static since we can resize the window and 2) the size of the LogBox's root should fill the *window* and not the screen. This diff fixes both of these issues.
Changelog:
[iOS][Fixed] - Ensure LogBoxView is sized relative to the key window instead of the full screen
Reviewed By: appden
Differential Revision: D34697076
fbshipit-source-id: 9665fd51bc86ed29837672cec882bac97904b0c8
Summary:
iOS will sometimes invoke the UIAlertAction handler for the cancel button more than once on iPad. This can be reproduced relatively easily by having a button that opens an action sheet and spam tapping outside the action sheet while it is opening. Since native module callbacks can only be invoked once this causes the app to crash here https://github.com/facebook/react-native/blob/main/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModule.mm#L206.
## Changelog
[iOS] [Fixed] - Fix action sheet callback invoked more than once on iPad
Pull Request resolved: https://github.com/facebook/react-native/pull/33099
Test Plan: Tested on iPad simulator to reproduce the crash and verified that this fixes it.
Reviewed By: philIip
Differential Revision: D34215327
Pulled By: ShikaSD
fbshipit-source-id: 6f406e4df737a57e6dd702dd54260aa72eab31d6
Summary:
Fix for iOS displaying a RedBox for LogBox handled errors, this has been happening since RN 0.65 (in 64.2 and earlier, if it was handled by LogBox then it wouldn't trigger RedBox)
Fixes https://github.com/facebook/react-native/issues/32106
## Changelog
[iOS] [Fixed] - Stop RedBox from appearing for LogBox handled errors
Pull Request resolved: https://github.com/facebook/react-native/pull/32641
Test Plan: Manually tested. Seems to fix things (and RedBox still displays for things like 'Could not connect to development server') but I would appreciate RSNara or someone else who is more familiar with the code to confirm that the original switch was a mistake and not something deliberately changed.
Reviewed By: christophpurrer
Differential Revision: D33661481
Pulled By: cortinico
fbshipit-source-id: c9c262adb3f977ae3f13beb9575d3eaa2445f663
Summary:
Resolves this issue: https://github.com/facebook/react-native/issues/32304.
**NOTE:** This PR is based on a prior PR for this fix: https://github.com/facebook/react-native/pull/32305, I've co-authorized its creator for this change (paddlefish).
Without this change, calling to hide an alert, leaves a `UIWindow` that blocks user interactions with the screen.
The correct way to remove a `UIWindow` in iOS is to set its hidden property to `YES`. Also, it is required to remove all references to the window (the associated `windowScene` for example) and ARC will automatically free this `UIWindow`.
The line after this change, set the `_alertWindow` reference to `nil`, but the window is already associated with a scene (see the screenshots from [this PR](https://github.com/facebook/react-native/pull/32305#discussion_r720521707)). So we also need to remove the `windowScene` from that window, as recommended by Apple: https://developer.apple.com/documentation/uikit/uiwindowscene/3198091-windows.
>To remove the window from the current scene, or move it to a different scene, change the value of the window's windowScene property.
## 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] [Fixed] - remove alert's window when call to `hide`.
Pull Request resolved: https://github.com/facebook/react-native/pull/32833
Test Plan: See https://github.com/facebook/react-native/pull/32305
Reviewed By: hramos
Differential Revision: D33460430
Pulled By: lunaleaps
fbshipit-source-id: b13c2c7ee6404f1e1c787265bc4af8a31005bcf1
Summary: Insert casts for implicit int -> CGFloat conversions. This warning category is generally benign and explicitly casting will preserve existing behavior.
Reviewed By: NSProgrammer
Differential Revision: D33303887
fbshipit-source-id: b21adbcf754e707adfe3f8eaa0fe9c3a65380cc5
Summary:
`_labelsForTags` is an array with string labels used only for local profiling, that we had to manually keep it in sync with `RCTPLTag`. Refactor so labels are assigned with switch instead.
Changelog: [iOS] Refactor: Assign string label to each case in RCTPLTag enum for startup performance logging
Reviewed By: fkgozali
Differential Revision: D32889043
fbshipit-source-id: 81da592a160a31b91e78289be0990cc2ff960f29
Summary:
The current implementation of the prelive composer is setting the RN override preference to nil when live shopping ends. However, if the user had a previously set appearance override, this would clear it out.
To resolve this, I cache the user's override preference before we override it, and restore it when live shopping ends.
Additionally, I'm adding a missing callback to restore the override pref when live shopping is dismissed, but not cancelled.
Changelog:
[ReactiveNative][Appearance] - Add function to retrieve overridden RN appearance
Differential Revision: D32564739
fbshipit-source-id: d0b4e06d2bbadad68f172d951609cba3e4587e5d
Summary:
The current implementation of `AccessibilityInfo.announceForAccessibility` will immediately interrupt any existing in progress speech with the announcement. Sometimes this is desirable behaviour, but often you will want to wait until existing speech is finished before reading the new announcement. This change gives us that option.
My personal use case for this feature is a custom text input. When typing on iOS with voiceover enabled, each character is read out after being selected. I wanted to add some additional information after each character to help with the context of what has changed in the input, but I didn't want to override the reading of the character itself.
This feature is supported natively on iOS by constructing an `NSAttributedString` with the property [`accessibilitySpeechQueueAnnouncement`](https://developer.apple.com/documentation/foundation/nsattributedstring/key/2865770-accessibilityspeechqueueannounce), so this change just adds an extra parameter to `AccessibilityInfo.announceForAccessibility` which controls the value of that property on the native side. Adding this as an extra optional parameter with false as the default ensures that existing uses of the function won't be affected.
Unfortunately, this feature doesn't appear to be supported on Android, so the new second property will be iOS only.
## Changelog
[iOS] [Added] - add new argument to announceForAccessibility to allow queueing on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/32637
Test Plan:
I've updated the `announceForAccessibility` section in RNTester with multiple buttons to demonstrate the difference between `queue: false` (default) and `queue: true` and show they work as intended.
Here's the expectation for each button:
- "Announce for Accessibility Immediately": on press, should start reading the button label, then be interrupted by the announcement
- "Announce for Accessibility Queued": on press, should read the button label then read the announcement afterwards
- "Announce for Accessibility Queue Multiple": on press, should read the button label, then read three announcements sequentially, no interruptions
You can see the realisation of those expectations in the following video recorded on an iPhone 12 running iOS 15.0.2:
https://user-images.githubusercontent.com/14826539/142770536-d57bfd69-eba5-444d-9c89-4bf4851ea062.mov
I've also tested the same way on an iPhone 8 running iOS 13.4 and it works exactly the same.
Reviewed By: yungsters
Differential Revision: D32637989
Pulled By: philIip
fbshipit-source-id: 3e90add523f11eb0eb34ea623211249263f257e2
Summary:
In this diff, it moves the codegen output location out of node_modules and to build/generated/ios folder.
A temp pod spec will be created so that those files will be included in the Xcode project.
Changelog: [Internal]
Reviewed By: hramos, cortinico
Differential Revision: D31809012
fbshipit-source-id: ba1c884c8024306ba0fd2102837b7dbebc6e18ac
Summary:
Fixes https://github.com/facebook/react-native/issues/32434: RCTLogBox window is orphaned, covering entire screen.
After this change, the logbox window once again is removed from the screen.
## Changelog
Some third-party SDKs may hold references to created UIWindow, UIViewController, or UIView objects. Doing so means that the current code's `hide` method that releases the reference to the UIWindow in LogBox will not cause the window to be dealloc'd, and thus instead it will remain on the screen. This change explicitly hides the LogBox window when the reference is released, so that even if some other SDK holds onto the window it will still be taken off the screen.
<!-- 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] [Fixed] - 32434
Pull Request resolved: https://github.com/facebook/react-native/pull/32435
Test Plan:
1. Use console.warn to generate a yellow warning message in log box. Also install a third-party SDK that holds onto a reference to UIWindow -- for example the Facebook SDK, the Data Dog SDK, or any number of other SDKs that use `swizzling` to intercept calls like `viewDidAppear:`.
2. click the log
3. tap "dismiss"
4. try to tap anywhere
5. Use Xcode view debugger to inspect the UI state
## Expected
The app still responds to the touch.
In Xcode, there is not an extra UIWindow covering the screen
Reviewed By: philIip
Differential Revision: D31794242
Pulled By: sshic
fbshipit-source-id: 28aa247b3ed3fd60b8e7c2ed7d0606cbf5c42408
Summary:
i saw this a lot in the codebase, it's not optimal bc we're using two selectors when we only need one.
fastmod --extensions m,mm '\[\[(.*) alloc] init]' '[${1} new]' --dir xplat/js/react-native-github/*
i manually updated the callsites that this codemod couldn't handle (e.g., where there were more than one of these instances in a single line)
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D31776561
fbshipit-source-id: 1b16da240e8a79b54da67383d548921b82b05a9f
Summary:
## Context
Right now we are using both LogBox and ExceptionsManager native module to report JS errors in ExceptionsManager.js, from below code we can tell they have some overlapping - when ```__DEV__ === true``` both could report the error.
https://www.internalfb.com/code/fbsource/[5fb44bc926de87e62e6e538082496f22017698eb]/xplat/js/react-native-github/Libraries/Core/ExceptionsManager.js?lines=109-141
## Changes
In this diff overlapping is removed: in ```ExceptionsManager.js``` LogBox will be responsible for showing the error with dialog when ```__DEV__ === true```, when it's prod we'll use ExceptionsManager native module to report the error. As a result LogBox and ExceptionsManager native module don't share responsibilities any more.
Changelog:
[General][Changed] - Remove shared responsibility between LogBox and ExceptionsManager native module
Reviewed By: philIip
Differential Revision: D30942433
fbshipit-source-id: 8fceaaa431e5a460c0ccd151fe9831dcccbcf237
Summary:
This PR fixes a few issues with the Appearance API (as noted here https://github.com/facebook/react-native/issues/28823).
1. For the Appearance API to work correctly on Android you need to call `AppearanceModule.onConfigurationChanged` when the current Activity goes through a configuration change. This was being called in the RNTester app but not in `ReactActivity` so it meant the Appearance API wouldn't work for Android in newly generated RN projects (or ones upgraded to the latest version of RN).
2. The Appearance API wasn't working correctly for brownfield scenarios on Android. It's possible to force an app light or dark natively on Android by calling `AppCompatDelegate.setDefaultNightMode()`. The Appearance API wasn't picking up changes from this function because it was using the Application context instead of the current Activity context.
3. The Appearance API wasn't working correctly for brownfield scenarios on iOS. Just like on Android its possible to force an app light or dark natively by setting `window.overrideUserInterfaceStyle`. The Appearance API didn't work with this override because we were overwriting `_currentColorScheme` back to default as soon as we set it.
## 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
-->
### Fixed
https://github.com/facebook/react-native/issues/28823
* [Android] [Fixed] - Appearance API now works on Android
* [Android] [Fixed] - Appearance API now works correctly when calling `AppCompatDelegate.setDefaultNightMode()`
* [iOS] [Fixed] - Appearance API now works correctly when setting `window.overrideUserInterfaceStyle`
Pull Request resolved: https://github.com/facebook/react-native/pull/29106
Test Plan: Ran RNTester on iOS and Android and verified the Appearance examples still worked [correctly.](url)
Reviewed By: hramos
Differential Revision: D31284331
Pulled By: sota000
fbshipit-source-id: 45bbe33983e506eb177d596d33ddf15f846708fd
Summary:
Changelog: [Internal]
https://fb.workplace.com/groups/rn.support/posts/6677051292343429
ax team is building a tool to extract information about the views for design reviewers, and RN has some AX information that is not working atm because of dependency on whether voiceover is on or not. so, this will give them the ability to programmatically set that field and hopefully be able to get accurate ax info
Reviewed By: ikenwoo
Differential Revision: D31010566
fbshipit-source-id: 4c8a33fce40266b270dd5994442c8472ca88f5dd
Paige Sun
Vincent Riemer
Lulu Wu
Gijs Weterings
Richard Howell
Ersan Kavafoglu
Phillip Pan
Chris Olszewski
Imran Shitta-Bey
CodemodService Bot
Erich Graham
Gabriel Donadel Dall'Agnol
Kudo Chien
Samuel Susla
Janic Duplessis
Moses DeJong
Liam Jones
Asaf Korem
Andres Suarez
David Ashinsky
Peter Carpenter
Nick Fujita
Sota Ogo
Andrew Rahn
Brent Kelly
Muhammad Numan
