Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42304
Changelog: [Internal]
Light refactor of `InspectorImpl`'s storage from two separate maps (one of them with tuples for values!) to a single map of objects.
Reviewed By: hoxyq
Differential Revision: D52786335
fbshipit-source-id: a49466ed7189fd032e486319bbdf77097a30885f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42301
Changelog: [Internal]
To simplify testing and rolling out the modern CDP backend in React Native, let's require the use of the C++ version of `InspectorPackagerConnection` whenever the modern CDP backend is in use, regardless of the `InspectorPackagerConnection` rollout setting.
Reviewed By: hoxyq
Differential Revision: D52786334
fbshipit-source-id: 5c12794e3faa2c094a23f69a5677f66905d1763e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42355
`RemoveDeleteTreeUIFrameCallback` operated directly on the view to clean up its children, which does not correctly account for subviews which have been clipped because they're outside the visible frame.
Changelog: [Android][Added] Added `removeAllViews` to IViewGroupManager.
Reviewed By: jehartzog, sammy-SC
Differential Revision: D52834835
fbshipit-source-id: fb7f07a17d07467eecd3ce9721afc2f3abcc0caa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42302
Changelog: [Internal][Added] Support launching experimental debugger frontend for CDP targets marked as "modern"
See the definition of "modern" targets in D50967795.
Reviewed By: hoxyq
Differential Revision: D52786332
fbshipit-source-id: 13718e9ddf3ec050049ef7ec9a77f6cf1a7f82ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42303
Changelog: [Internal]
Adds a coarse-grained mechanism to `inspector-proxy` for distinguishing between legacy and modern debug targets. The guiding principles are:
1. `inspector-proxy` does not interfere in the CDP message stream between the debugger frontend and a modern target, or in the lifecycle of a target.
2. Legacy runtimes (current React Native, React Native Desktop, etc) that rely on `inspector-proxy`'s existing invasive semantics must continue to work seamlessly for now. We'll decide on the right time to deprecate/remove this legacy code in the future.
NOTE: This is an experimental addition to the proxy protocol that may be replaced at any time.
Reviewed By: hoxyq
Differential Revision: D50967795
fbshipit-source-id: bb9c39a8fe755ef3661e2c61507dd324d8dc8894
Summary:
Added `--custom-resolver-options` to `--bundle` command. This options is also [available](https://github.com/facebook/metro/blob/main/docs/CLI.md#options) in Metro's CLI.
## Changelog:
[INTERNAL] [ADDED] - Add `--resolver-options` to `bundle` command
Pull Request resolved: https://github.com/facebook/react-native/pull/42333
Test Plan:
1. Build all packages by running `yarn build` in the root
2. Go to `packages/rn-tester` and run `npx react-native bundle --custom-resolver-options key=value` and the options should be passed to the Config.
Reviewed By: blakef
Differential Revision: D52869452
Pulled By: huntie
fbshipit-source-id: 9a2c2d94b72cfb47477cf58b9c0472c5a8551c84
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42282
Changelog: [Internal] `inspector-proxy` now assumes each app will report pages with locally unique IDs.
In order to simplify some upcoming logic changes in `inspector-proxy`, in this diff we begin to enforce the assumption that each app ( = platform-specific implementation of `InspectorPackagerConnection`) assigns a locally unique ID to each inspector page. The inspector proxy will silently drop page descriptors that have conflicting IDs, and log a message to `debug()`.
NOTE: As an implementation detail, integrators may use `DEBUG=Metro:InspectorProxy` to see debug messages from `inspector-proxy`.
Reviewed By: huntie
Differential Revision: D50969752
fbshipit-source-id: a4e6faa91d97594fc5343ce4bee66233523cd175
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42271
Changelog: [Internal]
Adds a util function to determine the `TurboModuleMethodValueKind` based on the `jsi:Value` type
Reviewed By: javache
Differential Revision: D52761045
fbshipit-source-id: de937cda67198aad962e63f41ccd42be6c00c0b8
Summary:
`UIMenuController` is deprecated as of iOS 16. https://github.com/facebook/react-native/commit/e08a1973f67d85acc157111c749c43572469e4c2 migrated a usage into an `available` check. However, it does not properly fall back to the deprecated API in the "else" block of the availability check, instead it uses an early return. It seems this means Xcode still sees the API as used, and spits out a deprecated warning. Let's just refactor the code so we don't have that anymore.
## Changelog:
[IOS] [FIXED] - Remove an early return to suppress a deprecated API warning for `UIMenuController`
Pull Request resolved: https://github.com/facebook/react-native/pull/42277
Test Plan: CI should pass.
Reviewed By: cipolleschi
Differential Revision: D52785488
Pulled By: sammy-SC
fbshipit-source-id: 0b47e8aa8d7c94728e3d68332fbb8f97f8ded34e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42328
This method was deprecated in 0.72. We're going to remove it in 0.74
Technically a breaking change, but users should not be using this method at all at this point.
Changelog:
[Android] [Removed] - Remove deprecated DefaultNewArchitectureEntryPoint.load overload
Reviewed By: mdvacca
Differential Revision: D52802644
fbshipit-source-id: f7c1db783959d93b81407847377f805d7ee2602d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42329
As the title says, this checks against illegal configurations of ReactFeatureFlags in DefaultNewArchitectureEntrypoint
and let the app crash if the user specified and illegal configuration
Changelog:
[Internal] [Changed] - Prevent illegal configurations of ReactFeatureFlags in DefaultNewArchitectureEntrypoint
Reviewed By: mdvacca
Differential Revision: D52802609
fbshipit-source-id: 7bc0a08c17430d7fd2448f65838ce47fad738883
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42327
This diff is the result of running
`buck2 run //xplat/js/scripts/rn-api:generate-rn-api-metadata`
After this lands, `react-native-android-breaking-change-detector` will actually be green again, after the previous diff fixed the infra setup.
Changelog: [General][Fix] Update stale ReactAndroid.api values after CI breakage
Reviewed By: cortinico, mdvacca
Differential Revision: D52800160
fbshipit-source-id: b96533baa1cb704ad43482d7a52db50e6dce9821
Summary:
This PR introduces the `vision` interfaceIdiom to check if the app runs on visionOS.
An update to the documentation should follow this change.
## Changelog:
[IOS] [ADDED] - Introduce `vision` interfaceIdiom
Pull Request resolved: https://github.com/facebook/react-native/pull/42243
Test Plan: This change has been used in `react-native-visionos` and the interfaceIdiom changes **only** when running in the non-compatibility mode. But it's still useful to have this upstream if at some point React native would compile to visionOS natively
Reviewed By: cortinico
Differential Revision: D52730028
Pulled By: cipolleschi
fbshipit-source-id: 711c5c2c6c7fe05b3ff8da7383b5e63e9e04acfa
Summary:
X-link: https://github.com/facebook/yoga/pull/1553
Pull Request resolved: https://github.com/facebook/react-native/pull/42274
Separate from `YGConfigSetPrintTreeFlag` we have a public API `YGNodeSetPrintFunc` which sets a function called, if you manually change a constant in source code during debugging.
This is not debug-only, is exposed as part of the public API (without a way to turn it on from the public API), and takes up a pointer per node doing nothing.
I'm not aware of anyone recently using the capability, and the tracing/event related work done since then would be more powerful for this anyway.
Remove the API.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D52767445
fbshipit-source-id: f72927b47cffa4fe6fe886b42f07cc1ba55f141e
Summary:
1. Modal onDismiss is not working on iOS (Fabric).
2. Modal onDismiss is currently only available on iOS. On Android, we don't have a way to know when exactly a modal is dismissed.
Currently, the onDismiss is emitted using a device event as a workaround to the RCTModalHostView unable to receive the component event as it's already unmounted when visible is false.
This PR removes the workaround and keeps RCTModalHostView mounted until the onDismiss event is emitted from the host and sends the onDismiss event on Android.
bypass-github-export-checks
## Changelog:
[ANDROID] [ADDED] - Added support for Modal onDismiss prop
[IOS] [FIXED] - Fix onDismiss is not working on Fabric
[General][Breaking] - The public API of Modal has changed. We don't have anymore a NativeModalManger turbomodule; RCTModalHostViewNtiveComponent's Prop does not require to pass an identifier anymore.
Pull Request resolved: https://github.com/facebook/react-native/pull/42014
Test Plan:
1. Run rn-tester
2. Open the Modal example
3. The second example shows the counter for the show and dismiss count
4. Show and dismiss the modal and verify the count is incremented correctly
https://github.com/facebook/react-native/assets/50919443/108bfb26-c8f6-43b2-ac40-f0b46e48771b
Reviewed By: javache, sammy-SC
Differential Revision: D52445670
Pulled By: cipolleschi
fbshipit-source-id: f419164032c3bef67387200778b274299bf0659f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42306
Internally, we have some computationally expensive checks in Debug mode when running Fabric.
However, these are not very useful in OSS and they were the cause of some issues which generated noise.
With this change, we are enabling those checks only in the Meta specific builds and making sure that the OSS won't incur in that cost.
## Changelog
[Internal] - Disable expensive Fabric checks when running Fabric in OSS
Reviewed By: cortinico, sammy-SC
Differential Revision: D52543696
fbshipit-source-id: 697f14fd21e884f293ea7cee8ee16fff73764996
Summary:
There seems to be a lot of `TARGET_OS_UIKITFORMAC` macro in React Native that don't need to be there. Let's remove them.
First off, what is `TARGET_OS_UIKITFORMAC` targeting? You might think it's [Mac Catalyst](https://developer.apple.com/mac-catalyst/), if you look at the [commit](https://github.com/facebook/react-native/commit/3724810d2168eb182db24acf9e741775df27ae13) introducing the ifdefs. However.. that doesn't seem right because `TARGET_OS_MACCATALYST` exists, and is used elsewhere in the codebase. In fact, if you look at this handy comment inside `TargetConditionals.h` (the file that defines all these conditionals), `TARGET_OS_UIKITFORMAC` is not even on there!
```
/*
* TARGET_OS_*
*
* These conditionals specify in which Operating System the generated code will
* run. Indention is used to show which conditionals are evolutionary subclasses.
*
* The MAC/WIN32/UNIX conditionals are mutually exclusive.
* The IOS/TV/WATCH/VISION conditionals are mutually exclusive.
*
* TARGET_OS_WIN32 - Generated code will run on WIN32 API
* TARGET_OS_WINDOWS - Generated code will run on Windows
* TARGET_OS_UNIX - Generated code will run on some Unix (not macOS)
* TARGET_OS_LINUX - Generated code will run on Linux
* TARGET_OS_MAC - Generated code will run on a variant of macOS
* TARGET_OS_OSX - Generated code will run on macOS
* TARGET_OS_IPHONE - Generated code will run on a variant of iOS (firmware, devices, simulator)
* TARGET_OS_IOS - Generated code will run on iOS
* TARGET_OS_MACCATALYST - Generated code will run on macOS
* TARGET_OS_TV - Generated code will run on tvOS
* TARGET_OS_WATCH - Generated code will run on watchOS
* TARGET_OS_VISION - Generated code will run on visionOS
* TARGET_OS_BRIDGE - Generated code will run on bridge devices
* TARGET_OS_SIMULATOR - Generated code will run on an iOS, tvOS, watchOS, or visionOS simulator
* TARGET_OS_DRIVERKIT - Generated code will run on macOS, iOS, tvOS, watchOS, or visionOS
*
* TARGET_OS_EMBEDDED - DEPRECATED: Use TARGET_OS_IPHONE and/or TARGET_OS_SIMULATOR instead
* TARGET_IPHONE_SIMULATOR - DEPRECATED: Same as TARGET_OS_SIMULATOR
* TARGET_OS_NANO - DEPRECATED: Same as TARGET_OS_WATCH
*
* +--------------------------------------------------------------------------------------+
* | TARGET_OS_MAC |
* | +-----+ +------------------------------------------------------------+ +-----------+ |
* | | | | TARGET_OS_IPHONE | | | |
* | | | | +-----------------+ +----+ +-------+ +--------+ +--------+ | | | |
* | | | | | IOS | | | | | | | | | | | | |
* | | OSX | | | +-------------+ | | TV | | WATCH | | BRIDGE | | VISION | | | DRIVERKIT | |
* | | | | | | MACCATALYST | | | | | | | | | | | | | |
* | | | | | +-------------+ | | | | | | | | | | | | |
* | | | | +-----------------+ +----+ +-------+ +--------+ +--------+ | | | |
* | +-----+ +------------------------------------------------------------+ +-----------+ |
* +--------------------------------------------------------------------------------------+
*/
```
Going even deeper into `TargetConditionals.h`, you will see `TARGET_OS_UIKITFORMAC` defined... and it's always 1 when `TARGET_OS_MACCATALYST` is 1, making it feel even more redundant. My current conclusion is it's either another variant of Mac Catalyst (the one where they just run unmodified UIKit maybe..), or it's an older macro back from when Catalyst was still experimental.
Either way, it's pretty obvious nobody is running or testing this codepath, and it adds bloat, especially to React Native macOS where we have extra ifdef blocks for macOS support (and eventually visionOS support). Let's remove it.
Another change I made while we're here:
I've seen this lingering TODO to replace setTargetRect:InView: / setMenuVisible:animated: (deprecated as of iOS 13, below our minimum OS requirement) with showMenuFromView (deprecated as of iOS 16, in line with the availability check). Let's just.... do that?
## Changelog:
[IOS] [REMOVED] - Remove TARGET_OS_UIKITFORMAC macros
Pull Request resolved: https://github.com/facebook/react-native/pull/42278
Test Plan:
RNTester with Mac Catalyst still compiles:

Reviewed By: cipolleschi
Differential Revision: D52780690
Pulled By: sammy-SC
fbshipit-source-id: df6a333e8e15f79de0ce6f538ebd73b92698dcb6
Summary:
This PR adds `get_folly_config()` to RCTAppDelegate, it was recently introduced here: https://github.com/facebook/react-native/issues/42153
## Changelog:
[INTERNAL] [CHANGED] - Unify folly version and compiler flags for RCTAppDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/42281
Test Plan: CI Green
Reviewed By: NickGerleman
Differential Revision: D52783503
Pulled By: cipolleschi
fbshipit-source-id: d1497371e84618f93abe8f7fab7ee0cdf5296d27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42291
In case someone tries to inline out-of-tree platform files with react-native JS Libraries files, it's useful to suppress issues with public API tests, as the public APIs are not intended to match yet.
## Changelog
[Internal]
Reviewed By: christophpurrer
Differential Revision: D52790636
fbshipit-source-id: 7bbaf8ae6d9571ed7d81d06ab4b82f67f518c5a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42300
Changelog: [Internal]
The version of the `keyword-spacing` lint rule we have installed is apparently buggy. Either way it's unnecessary since we use Prettier.
Reviewed By: christophpurrer
Differential Revision: D52799550
fbshipit-source-id: 2e199938d45c554039b2117163fd403f236bf752
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42267
In case anyone was to try linting the react-native repo with desktop out-of-tree platform files there, this makes things easier.
## Changelog
[Internal]
Reviewed By: christophpurrer
Differential Revision: D52746379
fbshipit-source-id: d59a1c1f9c84c6bee529d6bdd151a7ba680b6680
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42119
Changelog: [Internal]
- Updated spec for native commands of the DebuggingOverlay to have `Array` annotation instead of a workaround with string (and serialization)
- Removed serialization in JS and deserialization on native
Reviewed By: javache
Differential Revision: D51985222
fbshipit-source-id: 3dc5a049ae4984565df9ea32fa181c5885b79539
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41842
Changelog: [Internal]
- bumps `react-devtools-*` packages to 5.0.0 across xplat
- added support for highlighting multiple host components, when hovering over component, which is represented by multiple host fibers.
See test plan, this can be reproduced with a named component, which renders multiple host components inside a React Fragment:
```
<>
<View />
<View />
<View />
</>
```
Reviewed By: gsathya
Differential Revision: D51888628
fbshipit-source-id: 2bd2d9fa50c24f478aa9406ee6bb42a47168bf13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41843
Changelog:
[General] [Fixed] - inspected elements from React DevTools are now correctly highlighted on a relevant surfaces
For cases when DOM Node APIs are not available (Paper or Fabric without these APIs), we will use newly added `isChildPublicInstance` from renderer.
Similarly to D51713089, this updates implementations to highlight elements only on a single AppContainer.
Reviewed By: javache
Differential Revision: D51822874
fbshipit-source-id: d5992abed5ec6f11f04d2e1e6e6928c2a66aef7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41818
Changelog: [Internal]
Use `parentElement` API to find lowest AppContainer ancestor, which will be responsible for highlighting an inspected element or rendering trace updates frames on the screen.
Reviewed By: sammy-SC
Differential Revision: D51713089
fbshipit-source-id: d6d07481679484a518a05b58d4394999876ea7d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41816
Changelog: [Internal]
Forking implementations for trace updates and element highlights from React DevTools: modern and legacy.
Both implementations will later solve the same problem of highlighting the component only on a single AppContainer, but with different approaches:
- Modern will be based on DOM Node APIs: `getBoundingClientRect` and `parentElement`.
- Legacy will be based on `isChildInstance` from renderer and `measure`.
All corresponding API call will be added in a separate diff later on top of these changes.
Reviewed By: sammy-SC
Differential Revision: D51713087
fbshipit-source-id: 1c840d711a541085b1075711f737a8dbc1e31637
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41749
Changelog: [Internal]
- Each trace update frame will have its own unique id, which will be the react tag of the corresponding host fiber.
- Based on these ids, previous frames will be rerendered, not
just removed once new frames are sent from React DevTools.
- Imagine a case when there are 2 components on the screen: the first one rerenders once in a second and the second component rerenders much more frequently, each 5 milliseconds. With our previous implementation, update frames for first component will be removed once the second component has been rerendered.
- Each frame will have a lifetime for 2 seconds, it resets if frame with the same id was sent again from JS (basically component rerendered again, while we were highlighting it).
Android demo:
https://pxl.cl/3Vllz
Reviewed By: sammy-SC
Differential Revision: D51708054
fbshipit-source-id: 7abff9c1a334dccb3a1c08a46487d4bb99cdc448
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41746
Changelog: [Internal]
Now using previously added `highlightElements` and `clearElementsHighlights` commands.
[Improvement] Since DebuggingRegistry is a singleton, it will only subscribe to the React DevTools events once and not *number-of-rendered-AppContainers* times.
All required functionality for highlighting elements on a single AppContainer will be added in one of the next diffs of this stack, changes are incremental.
Reviewed By: sammy-SC
Differential Revision: D51708053
fbshipit-source-id: f94a1bb1f5b876a153d305eeacf65b8a5eca2a08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41745
Changelog: [Internal]
Support `highlightElements` and `clearElementsHighlights` commands in `DebuggingOverlay` native components.
These later will be used for highlighting inspected component in React DevTools. These commands unblock highlighting elements on the native side, currently we do it on JS side and it mutates the React tree.
We still need to serialize the array before passing it to the native command, because codegen doesn't support it yet.
Reviewed By: javache
Differential Revision: D51603861
fbshipit-source-id: da837b0fc32e36980f207166a679fb8124ff6100
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41744
Changelog: [Internal]
With these changes:
- DebuggingRegitry is responsible for listening to the events from React DevTools and
- AppContainer renders DebuggingOverlay component and subscribes with its reference to the DebuggingRegistry
- [Improvement] Since DebuggingRegistry is a singleton, it will only subscribe to the React DevTools events once and not *number-of-rendered-AppContainers* times
All required functionality for highlighting elements on a single AppContainer will be added in one of the next diffs of this stack, changes are incremental.
Reviewed By: sammy-SC
Differential Revision: D51603860
fbshipit-source-id: 92b029eb54ef63b27af970770eb522915578a0b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41743
Changelog: [Internal]
There will be a single DebuggingRegistry instance per runtime, which will be responsible for finding lowest AppContainer ancestor for highlighted component.
It will receive refs to root views (ancestors, AppContainers) as subscriptions and later will call all necessary methods.
In the next series of diffs, subscriber will also provide reference to the DebuggingOverlay, on which DebuggingRegistry can call all necessary methods to highlight elements.
Reviewed By: rshest
Differential Revision: D51536787
fbshipit-source-id: e89f9d466a7e7833733981ff0d3ce2dbe349aaaa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42249
Changelog: [Internal]
Manually patching public React renderers artifacts to include `isChildPublicInstance` method, which was added in https://github.com/facebook/react/pull/27783.
To identifly the required changes in code I've ran a diff for 2 commits:
1. The one with the changes
2. Its parent
FB implementation were synced in D51816108.
Reviewed By: sammy-SC
Differential Revision: D52697885
fbshipit-source-id: c62af6e89e8da3ee6f6c7264bacf6e96030e9db8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42285
Changelog: [Internal]
Having a static import of `ReactFabric` blocks from using `ReactNativeElement` class for Paper-only applications.
Although DOM Node APIs are Fabric-only, the ability to use `instanceof ReactNativeElement` is a nice tool for gating purposes, which currently can't be used because of the static import.
Reviewed By: rubennorte
Differential Revision: D52784886
fbshipit-source-id: 705c6ce0b5912d9857d730ebf1e1ecf629e2b8af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42247
With this change I make `ReactNativeConfig` a JNI class loaded at Fabric Loading time.
This removes the default from `EmptyReactNativeConfig.java` and makes sure we do read the defaults from C++ `ReactNativeConfig.cpp` file.
Changelog:
[Internal] [Changed] - Make ReactNativeConfig a JNI Class
Reviewed By: motiz88
Differential Revision: D52696653
fbshipit-source-id: 99d5e37c65e0e59efcee2c857bb94194fb40d87d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42287
Changelog: [Internal]
`run-ci-e2e-tests.js` currently skips past package build errors and tries to keep going. At best, this fails somewhere downstream of a build error (without any clear diagnostics as to why). At worst, this can miss errors entirely.
Here we extend the script's existing error handling behaviour to cover errors during the build script. It's probably worth following up to make sure all unexpected failures bubble up and stop the script, as opposed to the current error-swallowing default.
Reviewed By: hoxyq
Differential Revision: D52785131
fbshipit-source-id: 08deedfdf5b3d3cb63e77c74b47eb75570a58fbb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42248
I'm duplicating the AndroidManifest.xml file internally/externally as Gradle is really unhappy with it (and gets really noisy):
- It contains a package declaration which should be removed
- It contains a uses-sdk which should also be removed
Changelog:
[Internal] [Changed] - Fix AndroidManifest.xml for RN-Tester in OSS
Reviewed By: christophpurrer
Differential Revision: D52694108
fbshipit-source-id: bb88e6f58cc8cf3a624be4b58bb409535a283a77