Summary:
Add a `DevSupportManager` that can be used for performance testing. This `DevSupportManager` allows the inspector connection to be established, but leaves everything else disabled.
Previously, if Developer Support was enabled on a release build, the application would present an error as it unsuccessfully attempted to use the bridge dev support manager.
With this change, if a developer opts into developer support in a release build (i.e. `enableOnCreate == true && ReactBuildConfig.DEBUG == false` in the `DevSupportManagerFactory`), the `PerfTestDevSupportManager` will be used, allowing use of things like heap size reporting and the sampling profiler.
(`enableOnCrease` indicates the development mode setting: https://www.internalfb.com/code/fbsource/[6b8a941fdf2a0fd58d9db36f5a59fa5fb53ad2df]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManager.java?lines=259)
Changelog: [internal]
Reviewed By: rubennorte
Differential Revision: D39468561
fbshipit-source-id: cb3c82e7a8ee74316b23f57dc8d0cc6e5cdb18a7
Summary:
when specifying dev server without port, e.g. http://www.example.com/, there are some issues.
1. redbox error
<img src="https://user-images.githubusercontent.com/46429/190540390-8ee420f2-7642-427b-9f2e-e0c6d31015f8.png" width="30%">
2. showing -1 in loading view
<img src="https://user-images.githubusercontent.com/46429/190540727-158f35ad-359f-443a-a4b0-768dd2f7e400.png" width="50%">
the root cause is coming from [`java.net.URL.getPort()` will return -1 when the url doesn't have a port](https://developer.android.com/reference/java/net/URL#getPort()). this pr replaces the parser to [`okhttp3.HttpUrl`](https://square.github.io/okhttp/4.x/okhttp/okhttp3/-http-url/#port) that it will have default port 80 for http or port 443 for https. the two call paths should only serve http/https address, not file:// address. it should be safe to change from java.net.URL to okhttp3.HttpUrl.
not fully related, in the case above, android will connect to `ws://www.example.com/:8097` for react-devtools
we should strip the trailing slash in *setUpReactDevTools.js*
## Changelog
[Android] [Fixed] - Fix port as -1 if dev server without specifying port on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/34705
Test Plan:
test on rn-tester with the following steps
1. `yarn start`
2. open another terminal and run `ngrok http 8081` and it will return a tunnel url, e.g. `71a1-114-36-194-97.jp.ngrok.io`
3. open dev setting in app and change the dev server to `71a1-114-36-194-97.jp.ngrok.io`
5. reload the app
Reviewed By: cipolleschi
Differential Revision: D39573988
Pulled By: cortinico
fbshipit-source-id: 397df90ab30533207bd87a3f069132d97c22c7fd
Summary:
The `JSDevSupport` module is incompatible with Fabric. Given it's not used internally and it's undocumented in OSS, we decided to remove it altogether.
Changelog: [Internal]
Reviewed By: javache, nlutsenko
Differential Revision: D39305892
fbshipit-source-id: 82455701a0b9ba83e6f971fc774280dceb2b22e0
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:
The context could be null or is finishing when we create the redbox surface content view. This diff adds the null check and delegate the message in log when context is not available.
Changelog:
[Android][Fixed] - Adding null check for context in redbox surface delegate
Differential Revision: D34930595
fbshipit-source-id: 91508ded7821033abcd893f70bcfe3cc9ee5b5c2
Summary:
This diff adds `RedBoxSurfaceDelegate` to replace existing logic in `DevSupportManagerBase` to abstract how we show/hide the RedBox surface. The delegate will wrap a RedBoxDialog instance, which is used to show/hide the dialog for default behavior (when there is no surface delegate for redbox got provided).
I also updated the interface for delegate to accomodate new use cases:
- Add `isShowing` for the `SurfaceDelegate`
- Add a list of getters for `DevSupportManager` for data access in the delegate
- (Update 2/7) Separate Dialog from `RedBoxDialog`, and re-named it to `RedBoxContentView`. This is to make it clear that the delegate is responsible to provide actual surface implementation (Dialog). The content view is meant to be shared.
Changelog:
[Android][Internal]
Reviewed By: javache
Differential Revision: D33987835
fbshipit-source-id: 57c20648e7f2ec8238963feca27ccd5518e7931d
Summary:
Not setting locale for language/country neutral operation may cause bug depending on the default locale.
See https://docs.oracle.com/javase/7/docs/api/java/util/Locale.html#ROOT
Note: I am just searching for toLowerCase() and toUppercase() in my project's dependencies and send the same PR, in order to just be considered. Although I've seen the lack of explicit locale has caused issues for us, I am not sure if react-native is actually affected. I haven't checked for `String.format()` yet.
Example related issue: joltup/rn-fetch-blob#573
## Changelog
[Android] [Fixed] - Use root locale when converting string case.
Pull Request resolved: https://github.com/facebook/react-native/pull/33028
Reviewed By: ShikaSD
Differential Revision: D33943446
Pulled By: cortinico
fbshipit-source-id: d5be9392ea7c21a33436acac5b5e8c50b7c7e31e
Summary:
This diff separates the content view creation logic from existing `RedBoxDialog` logic. After the change, `RedBoxDialog` is no longer a subclass of `Dialog`, but behaves like a dialog with forwarding pattern to delegate dialog API to internal member. This will keep the APIs consistent with dependent components.
The motivation of the change is to make the content view reusable. This is important in VR surface where we don't have activities and necessary implementations for Dialog to show.
Changelog:
[Android][Internal]
Reviewed By: javache
Differential Revision: D34016503
fbshipit-source-id: 261594bda9f6fb2d83764a1e5ec2e9e60d8d39a3
Summary:
We put the `:interfaces` target on the dependencies list for `:devsupport` target in the [BUCK file](https://fburl.com/code/lrr1c0pn). In the following diffs I will need to put the interface [`/devsupport/RedBoxHandler`](https://fburl.com/code/v53euvps) on to [`/devsupport/interfaces/DevSupportManager`](https://fburl.com/code/k8gwxa0f). This violates the dependency rule.
Since `RedBoxHandler` is an interface, I moved it to the interfaces list in this diff to unblock.
Changelog:
[Android][Internal]
Reviewed By: yungsters
Differential Revision: D33987834
fbshipit-source-id: 77a1ee14bd10c6bbaac2ee465ae7050e99ed0399
Summary:
This diff introduces a new interface named `SurfaceDelegate`. The interface abstracts the API for interacting with a surface, which is required for platforms other than mobile to implement how it wants to show and hide a surface. For existing Mobile use cases, the `LogBoxDialogSurfaceDelegate` is provided as a fallback solution so everything still works.
Changelog:
[Android][Added] - Add SurfaceDelegate abstraction to support interaction in multiple platforms and provide default implementation in LogBoxModule
Reviewed By: mdvacca
Differential Revision: D31132285
fbshipit-source-id: 13315a8bc5b7bcaee9b5e53ef5c6f6cc8cb01f31
Summary:
to open possibilities for some DX enhancement, the pr introduces `DevSupportManagerFactory` customization. applications could implement a different DevSupportManager in ReactNativeHost.
## Changelog
[Internal] [Added] - Support custom DevSupportManager
Pull Request resolved: https://github.com/facebook/react-native/pull/31841
Test Plan: this pr just introduces some new interfaces and should not break existing functionalities.
Reviewed By: RSNara
Differential Revision: D30878134
Pulled By: yungsters
fbshipit-source-id: ccdf798caa322b07a876da8312b97002da057388
Summary:
Try to reuse currentActivity when the new context from "mReactInstanceDevHelper.getCurrentActivity()" is null to fix "Unable to launch redbox because react activity is not available..."
Changelog:
[Android][Fixed] - Fix currentActivity being null when launching Redbox
Reviewed By: philIip
Differential Revision: D30942434
fbshipit-source-id: faf03390adc545376f3cec223eac5a16bf8233ea
Summary:
Merges the Facebook-internal Buck target definitions in `Libraries/` into the BUCK file at the root of the repo (which is currently not synced to GitHub at all). This does not affect how React Native is built in open source.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D27967499
fbshipit-source-id: 39c51a544b3868242598072d24cb6cfb5a6e2d8c
Summary:
Changelog: [Internal]
Separate the functionality of the isPackagerRunning() function into a new class PackagerStatusCheck with the intention of being able to use this without needing a DevServerHelper
Reviewed By: makovkastar, ShikaSD
Differential Revision: D29933318
fbshipit-source-id: d708bb987b08634015d6ee6b6c8989faba416c5a
Summary:
Rationale:
- This makes the element inspector button consistent with the Fast Refresh, Perf Monitor and other buttons in the DevMenu
- This makes the button more informative
Changelog: [Android][Changed] Rename the "Toggle Inspector" DevMenu item to "Hide/Show Element Inspector"
Reviewed By: JoshuaGross
Differential Revision: D29146871
fbshipit-source-id: 8e8c19217ea2ff2f1d176521aa22200058e7e643
Summary:
Before the DevMenu would just open up as a DialogBox. After this change, the DialogBox will have a title. This should help distinguish between the Bridgeless DevMenu and the Bridge DevMenu.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29071185
fbshipit-source-id: 72533f10b73b36cd890fe152c6de901c867159f2
Summary:
With bridgeless mode enabled, there can be two instances of DevSupportManager. Previously, both of them wrote to the same files on disk. After this change, each instance will write the bundle to different files on disk.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D29068794
fbshipit-source-id: 67270be17d084cc89ab618ea54f729f9b595b5f7
Summary:
Google Chrome debugging is only supported by the bridge. So, it makes sense to move it to BridgeDevSupportManager.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29031514
fbshipit-source-id: 4d6b6bb3bc298be5fe4d9f96c0d019676fe256db
Summary:
## Rationale
The public methods of PackagerCommandListener should not be a part of the public API of DevSupportManagerBase. It's cleaner to just create a new PackagerCommandListener object inline, when we need it. This way, there're are less methods to think about when reasoning about the public API of DevSupportManagerBase.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29006835
fbshipit-source-id: 0eea86c22e7d676c94d29b240a1f39955d8216ab
Summary:
## Rationale
This reduces the surface area of DevSupportManager's public API.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29006836
fbshipit-source-id: 579364f6c556b8588f3b6bac79df3deb244a92e5
Summary:
## Rationale
This DevSupportManagerBase constructor isn't used anywhere, aside from VeniceDevSupportManager. Even in VeniceDevSupportManager, we should use the more specific constructor, because it informs readers of the class what specifically is being nullified in the base class. So, this diff gets rid of the smaller arity constructor.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004542
fbshipit-source-id: 74e20db93cf1871a364bf228dc089cd7d124297f
Summary:
## Rationale
DevSupportManagerBase.handleReloadJS() implements reloads for the bridge. Therefore, it's best to move this method to BridgeDevSupportManager.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004541
fbshipit-source-id: f77244e9c44cd442e7e0ab2845f78d699b143e66
Summary:
## Rationale
Throughout DevSupportManagerBase, we show/hide the DevLoadingView and simultaneously write to the `mDevLoadingViewVisible` boolean. This diff pulls all those boolean writes into methods, so that subclasses of DevSupportManagerBase can show/hide the DevLoadingView without accessing the boolean directly.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004062
fbshipit-source-id: d54d79701e31f9ac8d1d1d44019199718fe1c8c0
Summary:
## Rationale
DevSupportManagerBase.loadSplitBundleFromServer() uses the bridge. So, it's best to move it to DevSupportManagerBase.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29004064
fbshipit-source-id: 9acfb769d57a44ee4871e1997ff0950c3d66b757
Summary:
## Rationale
- AsyncDevSupportManager.loadSplitBundleFromServer() is an override of DevSupportManager.loadSplitBundleFromServer(), which is used by the bridge. However, AsyncDevSupportManager.loadJSBundleFromServer() has no bridge analogue. This is confusing: Are the methods in AsyncDevSupportManager Venice overrides for bridge related methods? It's easy to think yes, but the answer is no.
- AsyncDevSupportManager.loadJSBundleFromServer() is an additional layer of indirection that provides very little value: all it does it create the JSBundleLoader, and call onReactContextCreated. However, it does so in 11 lines of very confusing code.
A discussion we don't have to have now: Inheritance hierarchies are very difficult to understand and de-tangle. So, instead of using inheritance to make DevSupportManager work with Venice (via AsyncDevSupportManager), should we just refactor DevSupportManager so that it can be customized to work with Venice?
Changelog: [Internal]
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D27577591
fbshipit-source-id: b64dcd65e9a7c85b89443d860d441a0635547916
Summary:
Sometimes ```hasActiveCatalystInstance()``` is used to check if it's safe to access the CatalystInstance, which will still crash in Venice.
Previously we mitigate this by changing ```reactContext.hasActiveCatalystInstance()``` to ```reactContext.hasActiveCatalystInstance() || reactContext.isBridgeless()```.
To solve this for all and good the plan is:
1, Rename ```hasActiveCatalystInstance()``` to ```hasActiveReactInstance()``` so it won't sounds like CatalystInstance-only.
2, Implement hasActiveReactInstance() for Venice. D27343867
3, Remove previous mitigation. D27343952
This diff is the first step, by xbgs there are **58** non-generated callsites of ```hasActiveCatalystInstance()``` in code base which are all renamed in this diff.
Changelog:
[Android][Changed] - Rename "hasActiveCatalystInstance" to "hasActiveReactInstance"
Reviewed By: mdvacca
Differential Revision: D27335055
fbshipit-source-id: 5b8ff5e09b79a492e910bb8f197e70fa1360bcef
Summary:
In DevSupportManagerBase.java->updateLastErrorInfo(), errorType was not recorded like errorMessage and errorStack, we could either remove errorType as a parameter or recorded it for future use. This diff recorded it since it would make the error info complete.
Changelog:
[Android][Changed] - Record latest error type in dev support
Reviewed By: PeteTheHeat
Differential Revision: D26884647
fbshipit-source-id: 712d82667bdc4b3410f4c83a3df9a456af6d9061
Summary:
This diff migrates all NativeModules away from onCatalystInstanceDestroy() to the invalidate() method.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D26871595
fbshipit-source-id: 132f6b75e485361835769a2b53bc742eefa47b59
Summary:
## Description
Suppose this was the codegen declaration before:
```
rn_library(
name = "FooModule",
native_module_spec_name = "FBReactNativeSpec",
codegen_modules = True,
# ...
)
```
Previously, this would generate the following BUCK targets:
- generated_objcpp_modules-FooModuleApple
- generated_java_modules-FooModuleAndroid
- generated_java_modules-FooModule-jniAndroid
## Changes
We will now generate:
- FBReactNativeSpecApple
- FBReactNativeSpecAndroid
- FBReactNativeSpec-jniAndroid
This matches the naming scheme of the old codegen.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D25680224
fbshipit-source-id: 617ac18fd915f3277f6bd98072d147f20fb193e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30595
Changelog: [Internal]
Add support for loading HBC bundles from Metro in Twilight.
* adds `runtimeBytecodeVersion` to the bundleURL
* adds logic to check chunk hermes bytecode bundles
* adds support for running the bytecode bundles
Reviewed By: cpojer
Differential Revision: D24966992
fbshipit-source-id: acdd03a2e9e2b3e4c29c99c35a7c9136a3a7ef01
Oleksandr Melnykov
Riccardo Cipolleschi
Jonathan Keljo
Stanley Shi
Matt Blagden
Joshua Selbo
Kudo Chien
Rubén Norte
Ron Edelstein
Lulu Wu
Chris Olszewski
CodemodService Bot
Xin Chen
Hamid
Mengke Ding
Andres Suarez
Andrei Shikov
Moti Zilberman
Amy Nichol
Ramanpreet Nara
Keion Anvaripour
