Summary:
Since the Sandy wrapper is now rolled out to 100%, removing the GK. Further code cleanup in next diffs.
Changelog: Flipper that don't use the new Sandy plugin format yet (see https://fbflipper.com/docs/extending/sandy-migration) will now always be loaded inside a legacy container
Reviewed By: timur-valiev
Differential Revision: D29394736
fbshipit-source-id: f7a7c321c6b6a82470d47e4352d86135c3849b82
Summary: As we now allow selection of disabled plugins we need to track plugin usage a bit smarter. We'll add a new field "pluginEnabled" to the logged messages to indicate whether selected plugin is enabled or not.
Reviewed By: cekkaewnumchai
Differential Revision: D29455248
fbshipit-source-id: 32c79e0961653edc8f4cc89adecc2662b37cbd7b
Summary: Use selectors to re-compute and cache plugin lists according to the selected device and app.
Reviewed By: mweststrate
Differential Revision: D29247845
fbshipit-source-id: 4bc669d5d441d605c4090086c4ce59b6d9684a4c
Summary: Changed unit test infra to wrap legacy plugins by default in Sandy, and adapted tests where needed.
Reviewed By: nikoant
Differential Revision: D29264660
fbshipit-source-id: fe7cbc8af826afac5f945103586b3cb9647e7fbd
Summary: Changed some imports, and again the Flipper initialisation broke. Refactored the store initialization to create nowhere module local constants, which prevents generally against module loading issues, making it possible to load all code first, and then intialise things through the `init()` method, which should make Flipper initialisation a lot more robust to changes
Reviewed By: passy
Differential Revision: D29233603
fbshipit-source-id: 322cb87cba23228b1d7a88634b7b3995e27cc277
Summary:
This diff introduces loading classic Flipper plugins in a Sandy container. By wrapping plugins into Sandy we will be able to remove a lot of code / logic duplication related to state, queue processing, serialization etc. This will allow us to remove most or all of the complex plugin logic from the old system, only keeping onto the legacy components which have a lower maintenance burden. Until all plugins are Sandy.
This diff is not feature complete but only implements the core mechanisms for (persisted) state and communication.
Keyboard support, serialization, and rewiring tests etc will be added in next diff.
The feature is introduced behind GK flipper_use_sandy_plugin_wrapper to have kill switch.
Tests will be added later in this diff by redirection a part of the current mechanisms to wrapped plugins. (Will land the stack as a whole)
Reviewed By: passy
Differential Revision: D29165866
fbshipit-source-id: 57f84794a4a5f898bf765ce2de13cc759267fbc6
Summary: This is purely refactoring change. Before that we computed plugin lists in-place in PluginList component. Now we will be re-computing them as side effect and will keep computed lists in redux. This makes it easier to re-use plugin lists in other places outside of PluginList component, e.g. in the upcoming Marketplace UI.
Reviewed By: mweststrate
Differential Revision: D29161719
fbshipit-source-id: 5cb06d4d8a553aa856101c78b2311fbc078c6bd7
Summary:
If port 8088 / 8089 are in use, devices will not be able to connect to Flipper. We have checks for this in place, however it turns out that users can miss them. Potentially this can be caused for mulltiple reasons:
1. The notification is shown fairly short (in my testing it disappeared sometimes in < 2 secs
2. The notification is shown outside of the Flipper area
3. Flipper might not have permissions to show notifs in the first place.
Changed the notification to show inside Flipper, not hide automatically, and added clearer instructions. Including mentioning the port number (since there are multiple)
Changelog: [Flipper] Provide clearer error if Flipper ports are already in use, making device connections impossible
Differential Revision: D29128014
fbshipit-source-id: 16d9b451aa84281744155bfa1042429911a7b774
Summary:
Concatenating strings is not a great idea for paths. This isn't actually Windows-specific (I think) but maybe more common there. If you have a space as part of your ADB path, you're in for a world of pain.
This addressed a couple of issues but I'm sure there are more when you use it for more detailed use cases.
Closes https://github.com/facebook/flipper/issues/2438
Reviewed By: mweststrate
Differential Revision: D29061367
fbshipit-source-id: 001e498ac42bd8df6e6852be9b42fb5f38379c2e
Summary: Improved message a bit to make it clear that VPN/Lighthouse is required on both sides - computer and mobile device. Also it will now show login link in case user is not signed in yet, because login is also required for www cert exchange.
Reviewed By: passy
Differential Revision: D28899558
fbshipit-source-id: 89de776f602a9f27a2c068efd8e3f08c28ec5f57
Summary: SignInSheet and "dispatcher/user" are not used in public build, so it doesn't make sense to keep them on github.
Reviewed By: passy
Differential Revision: D28789384
fbshipit-source-id: aa1ab0fc70f2211260017be42762714b753ea877
Summary:
This diff generalises computation of the currently selected plugin, app, device etc. and adds this information to all the analytics events and error reports.
Slicing of events by os, device, app or selected plugin can be very useful. This is especially true for errors which often affects only certain types of devices, e.g. android only or physical devices only. Having such information can help to narrow down such issues.
Reviewed By: passy
Differential Revision: D28511441
fbshipit-source-id: ed9dc57927c70ed8cc6fe093e21604eae54c2f60
Summary:
One is keytar, which just needed a context.
The second one is happening every time someone uses Flipper
and not being on Lighthouse, spamming our log category besides
actually being properly handled.
Reviewed By: nikoant
Differential Revision: D28479791
fbshipit-source-id: 029721df46d12b2942b590a232618ef039a2323d
Summary:
Sorry for long diff! I can try to split it if necessary, but many changes here are 1-1 replacements / renames.
**Preambule**
Currently we bundle default plugins into the Flipper main bundle. This helps us to reduce bundle size, because of plugin dependencies re-use. E.g. if multiple plugins use "lodash" when they are bundled together, only one copy of "lodash" added. When they are bundled separately, the same dependency might be added to each of them. However as we're not going to include most of plugins into Flipper distributive anymore and going to rely on Marketplace instead, this bundling doesn't provide significant size benefits anymore. In addition to that, bundling makes it impossible to differentiate whether thrown errors are originated from Flipper core or one of its plugins.
Why don't we remove plugin bundling at all? Because for "dev mode" it actually quite useful. It makes dev build start much faster and also enables using of Fast Refresh for plugin development (fast refresh won't work for plugins loaded from disk).
**Changes**
This diff introduces new option "no-bundled-plugins" for "yarn start" and "yarn build" commands. For now, by default, we will continue bundling default plugins into the Flipper main bundle, but if this option provided then we will build each default plugin separately and include their packages into the Flipper distributive as "pre-installed" to be able to load them from disk even without access to Marketplace.
For "yarn start", we're adding symlinks to plugin folders in "static/defaultPlugins" and then they are loaded by Flipper. For "yarn build" we are dereferencing these symlinks to include physical files of plugins into folder "defaultPlugins" of the produced distributive. Folder "defaultPlugins" is excluded from asar, because loading of plugins from asar archive might introduce some unexpected issues depending on their implementation.
Reviewed By: mweststrate
Differential Revision: D28431838
fbshipit-source-id: f7757e9f5ba9183ed918d70252de3ce0e823177d
Summary:
This diff fixes several existing issues in the React DevTools:
Every time the user opened the plugin we re-instantiated the devtools, which has a few problems: 1) it looses all state (e.g. selection), and 2) this causes the tools to start a websocket listener on a new port, that was never cleaned up, or ever used, since React Native always connects to port 8097 anyway.
To preserve the state the idea of the original implementation was to move the devTools out of the current view, without disposing it. This actually didn't work in practice due to a faulty implementation, causing a full reinialization of the tools every time. Addressed this by reusing the mechanism that is used by the Hermes debugger tools as well.
By properly managing the port (e.g. closing it), there is no need to start (in vain) the devTools on a random port.
Port reversal for physical devices needs to happen only once, in principle upon connecting the device, so moved it to the device logic, which also avoids the need to hack into the global Flipper store.
Avoiding recreating the devTools makes plugin switching near instant, instead of needing to wait for a few seconds until the devTools connect.
When multiple apps are connected the behavior is now consistent: the application that refreshed last will be the one visible in the devTools. (That is still pretty suboptimal, but at least predicable and not a use case that is requested / supported in the DevTools themselves atm)
There is still ugly DOM business going on, did put that in a stand alone component for now.
Didn't extract the shared logic with Hermes plugin yet, but did verify both are still working correctly.
Changelog: [React DevTools] Several improvements that should improve the overal experience, the plugin should load much quicker and behave more predictably.
Reviewed By: bvaughn
Differential Revision: D28382587
fbshipit-source-id: 0f2787b24fa2afdf5014dbf1d79240606405199a
Summary: We currently filtering out incompatible versions from marketplace. This diff also add filtering for incompatible installed plugins on Flipper startup to ensure we always load the latest compatible version.
Reviewed By: passy
Differential Revision: D28341891
fbshipit-source-id: 83afc14a3c07e1763e1bd146251e6d3b71a66248
Summary:
Fixed a bug when plugin installation status wouldn't be saved between sessions when plugin uninstalled and then re-installed again. Before the fix, after Flipper restart, such plugin was uninstalled again because its package name was not removed from "uninstalledPlugins" state. This was because plugin id was used by mistake instead of name in few places.
To try avoiding this issue in future I've also renamed "uninstalledPlugins" to "uninstalledPluginNames" to make it more clear than package name should be used there rather than ID. As this field is persisted, I also added migration which moves data to the renamed field.
Reviewed By: passy
Differential Revision: D28314447
fbshipit-source-id: fbe3edc258b78fe7fbb0d966f93aabcdf3b66d4b
Summary: I've noticed that Flipper is trying to schedule auto-update for some plugins on every startup even though they are already updated. I found this happens because of a race condition when the auto-updater can be triggered before plugins initialised. This diff fixes that.
Reviewed By: passy
Differential Revision: D28312086
fbshipit-source-id: 66b0bd2aa9dfede1737d565b1e7e7845c940405e
Summary: Currently, when user installs a new plugin which was not installed before that, Flipper always takes the latest available version of it. This is not correct, because the latest version might be incompatible with the currently running version of Flipper. To avoid that, instead of always using just the latest version we will be using the most recent version which is compatible with the current Flipper version.
Reviewed By: passy
Differential Revision: D28306505
fbshipit-source-id: 4258a456d6a5d92cbf48af55c0efb17ecf560b57
Summary:
Changelog: Fixed application crash notifications not opening the crash log
Crashlog notifications were quite blatantly broken:
1. Because I force all GK's to true locally during testing, and the feature gate is negative, I never had any crash reports in the first place. The GK was empty so removed it.
2. The notifications overview would always cause a NPE when the notification came from a device plugin (it assumed a client to be present). This made the button do nothing and the device name not show up near the notification
3. The OS level notifications would link to the notification screen, which was a static screen in the classic UI and would always render to an empty page in Sandy. Removed that screen from the code base. Instead the click the notification will now trigger the notification action.
Reviewed By: passy
Differential Revision: D28119719
fbshipit-source-id: 5b28dd854260fd479d09e3ee6206301cc669ab40
Summary:
I was a dummy and ran into this. Tried to make it easier
for the next person to figure out what this means.
Reviewed By: mweststrate
Differential Revision: D28026376
fbshipit-source-id: ad3455938ef30b448b475cb990f86351e76628bf
Summary: We received questions several times from plugin authors on how to find usage for particular app/platform and I wanted to add that data on plugin usage dashboard, but right now it's impossible. We're only collecting plugin ID as a part of plugin usage analytics. That means it's impossible to filter some plugin usage (e.g. "Network") by particular platform or mobile app. This diff improves plugin usage analytics to collect enhanced data.
Reviewed By: passy
Differential Revision: D27935801
fbshipit-source-id: c2fc7d8cf84f9a28823ae56a1dda7158e0b12f1f
Summary:
It looks like electron creates new native window object after each window refresh, but we hold previous objects because of listeners attached to them. In dev mode, Electron signalises about that in console log each time when window is focused / blured after refresh:
```
Attempting to call a function in a renderer window that has been closed or released.
Function provided here: init-fast-refresh.bundle?platform=web&dev=true&minify=false:800356:19
```
Reviewed By: passy
Differential Revision: D27619305
fbshipit-source-id: 51d1590903a37dba721fb7a711fdebb9f0034b98
Summary:
According to Google, ANDROID_HOME is deprecated.
This means, that having only ANDROID_SDK_ROOT as environment variable leading to Android SDK is enough.
Flipper supports only ANDROID_HOME, so I would like to add ANDROID_SDK_ROOT support.
However, there is a set of rules of ANDROID_HOME and ANDROID_SDK_ROOT priority.
Everything is mentioned on a this page: https://developer.android.com/studio/command-line/variables
## Changelog
Added ANDROID_SDK_ROOT environment variable support
Pull Request resolved: https://github.com/facebook/flipper/pull/2106
Test Plan: Probably I would need a help with this
Reviewed By: mweststrate
Differential Revision: D27505024
Pulled By: passy
fbshipit-source-id: 8bdc66a9652c673fd44944d87af1efc9e93d0f1b
Summary: Found an NPE during testing a prod build that I encountered a few times before, which occurs when the user isn't logged in. Maked types stricter and this probably fixes an old bug where login status icon could be out of sync as well.
Reviewed By: nikoant
Differential Revision: D27589740
fbshipit-source-id: 419aaca77a997e01e8d9b0067e604a8dad019551
Summary:
Based on issue https://github.com/facebook/flipper/issues/1509 I needed a custom port for the metro server to pass to flipper.
## Changelog
introduce `METRO_SERVER_PORT` env variable to be able to customize default 8081 port on startup.
Pull Request resolved: https://github.com/facebook/flipper/pull/2050
Test Plan:
Tested with a locally built linux desktop app, this seems to work OK pour hermes debugging & RN logging.
React DevTools don't seem to find the running app, maybe there's a mapping to handle there too ?
Reviewed By: jknoxville
Differential Revision: D27339006
Pulled By: passy
fbshipit-source-id: b1700c4fe73f14bf4617e23583b2954012e0a5aa
Summary:
Changelog: Logs plugin now supports physical iOS devices
As reported in https://github.com/facebook/flipper/issues/262 and linked papercut.
This diff adds support for iOS device logs through idb. Since idb doesn't respect `--json` flag at the moment, we perform the parsing in Flipper itself.
Reviewed By: passy
Differential Revision: D27346262
fbshipit-source-id: 3b314716f48bb9a7fe709370303396a51893359c
Summary:
D24358369 (8a31e984b3) introduced a dependency outside the `sonar/` dir, which probably should not have happened. D27324576 finally broke this, by adding a dep to QPL core, which will never be installed in our CI.
This diff unbreaks that rewriting the require to a locally provided version of crc32, however this is a stop gap, and it would be great if someone would look into a sustainable solution :)
Reviewed By: passy
Differential Revision: D27327272
fbshipit-source-id: 70cdf21c7ecf081ef804d6338ec11e498e3cb7cf
Summary: `onRegisterDevice` device abstraction was only used by the CrashReporterPlugin, and since with Sandy plugin lifecycles every plugin can do 'on-load' logic, we don't need it anymore.
Reviewed By: priteshrnandgaonkar
Differential Revision: D27046711
fbshipit-source-id: 16c567c60ed29a50017d525a2b707ee696a99e62
Summary: Exposed the `pluginKey` to sandy plugins (which we will use later for storing table preferences per plugin). And a little moving code around because circular deps problem roared its ugly head again.
Reviewed By: nikoant
Differential Revision: D27009721
fbshipit-source-id: 7ad29e72ff8028c9daae270c4749b657bd8ff049
Summary:
This diff adds the support of detecting physical device in Flipper even if the xcode is not installed and there is no cli tool installed.
See the demo.
Reviewed By: timur-valiev
Differential Revision: D26816588
fbshipit-source-id: 5f052998fcbe5c51385222d16df0e1855177b552
Summary:
Fixing the previous resulted in a next exception, where blur / focus might be triggered directly as side effect of some running logic. I think this happens when entering a debugger statement causing the window to loose focus in favor of the devtools.
Wrapped the logic in setImmediate to make sure that it runs on its own stack, since this will prevent any potential future issues with programmatically focussing / blurring as well.
Reviewed By: jknoxville
Differential Revision: D26814270
fbshipit-source-id: 5ca430653a219d3c98d8bf925277de67d8a9eb20
Summary: This is just an early start of centralising some ad-hoc logic we've got all over the place right now. Memoised do-we-have-idb calls with concatenated shell invocations. This gives us the opportunity to do a bit of testing, too.
Reviewed By: mweststrate
Differential Revision: D26694863
fbshipit-source-id: cd2b9883f90397802bbaae6030f7cb3881c565c2
Summary:
Fixes https://github.com/facebook/flipper/issues/1989
We had some self healing side effect that would destroy devices when registering a new device with the same serial, if they weren't yet. Redux isn't too happy about that, causing the attached crash.
Instead introduced a utility to destroy devices, and log an error if the device life cycle isn't respected by the device implementations, rather than crashing we will now just waste some memory.
Changelog: Fix a crash when disconnecting metro devices
Reviewed By: passy
Differential Revision: D26749214
fbshipit-source-id: 4c185ac521d44c1337fac8a9145440123b8b784c
Summary:
Changelog: Flipper will no automatically select any newly connected client
This reverts D26250896 (2df117923c) to V5, which is to aggressively select new clients. The current behavior was too conservative and caused Flipper to jump to a different client, without returning, after reconnecting a disconnected device.
As reported in https://fb.workplace.com/groups/flippersupport/permalink/1084676302013027/
Reviewed By: fabiomassimo
Differential Revision: D26691046
fbshipit-source-id: b16af2052f58dc1d4254eb1e6ebbb5848c53ed7e
Summary:
Renamed actions "star" and "unstar" everywhere to "enable", "disable" and "switch". The logic behind original "star" action changed significantly, so this rename just makes everything much clearer.
Please note that as a part of rename persisted state fields "userStarredPlugins" and "userStarredDevicePlugins" were renamed. I've added a "redux-persist" migration for seamless transition.
Reviewed By: passy
Differential Revision: D26606459
fbshipit-source-id: 83ad475f9b0231194701c40a2cdbda36f02c3d10
Summary:
This is a very simple implementation of "profiles". It allows defining sets of plugins and associate them with GKs. Plugins from sets are automatically installed and enabled when a mobile app connected to Flipper for the first time (e.g. user has not already debugged same app before). Set is only enabled if user is passing the associated GK.
Sets are simply hardcoded for now.
Reviewed By: timur-valiev
Differential Revision: D26605371
fbshipit-source-id: 9bf0600d44381e047361d960558aa004960550c1
Summary:
None of these are fatal. In fact, they're quite common for people
who've got Android enabled but no tools installed. So they're warnings
at best.
I'd like to find a way to guide people to the settings in this case
or use Doctor to disable Android support instead of retrying this
endlessly.
Reviewed By: mweststrate
Differential Revision: D26547577
fbshipit-source-id: 81e658fe3d95b2d12e76e4b635575f3e5a6fc53b
Summary: There is a bug right now that even for disabled plugins we're loading them. In particular, this led to the Flipper freezes caused by Logs plugin even if it is disabled.
Reviewed By: passy
Differential Revision: D26503012
fbshipit-source-id: 2068626f4637ced44c457ee1b7ba7fffdcf5aa47
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/1939
This diff fixes T84865014. We used to assume in our xcode cli check that xcode will be run from standard /Applications folder. But as mentioned in the above tasks, its not always true.
Reviewed By: passy
Differential Revision: D26484287
fbshipit-source-id: 32d343dece53576f99cbbb6d193138e803505935
Summary: Show warnings for the device plugins defined in the legacy format and suggest to migrate them
Reviewed By: mweststrate
Differential Revision: D26459321
fbshipit-source-id: 4e45cd58a63a4ff9903ecaf12e6f9ba4a43e71e1
Summary:
*Stack summary*: this stack adds ability to manage device plugins in the same way as client plugins: install, update, uninstall, enable (star) and disable (unstar) them.
*Diff summary*: implemented all plugin management actions for device plugins.
Changelog: it is now possible to enable/disable and install/uninstall device plugins
Reviewed By: mweststrate
Differential Revision: D26337377
fbshipit-source-id: 7d1ed61a8dc5f3339e5e548c613b67bca0c27f4f
Summary:
*Stack summary*: this stack adds ability to manage device plugins in the same way as client plugins: install, update, uninstall, enable (star) and disable (unstar) them.
*Diff summary*: changed the way how plugin compatibility with devices is checked from dynamic call to "supportsDevice" to static checks of "supportedDevices" metadata property which make it possible to check compatibility without even downloading plugin from Marketplace.
Changelog: plugin compatibility with devices is now checked according to metadata in property "supportedDevices" in package.json
Reviewed By: mweststrate
Differential Revision: D26315848
fbshipit-source-id: 6e4b052c4ea0507ee185fc17999b6211cdb11093
Summary:
*Stack summary*: this stack refactors plugin management actions to perform them in a dispatcher rather than in the root reducer (store.tsx) as all of these actions has side effects. To do that, we store requested plugin management actions (install/update/uninstall, star/unstar) in a queue which is then handled by pluginManager dispatcher. This dispatcher then dispatches all required state updates.
*Diff summary*: refactored "star plugin" operation to perform it in pluginManager dispatcher.
Reviewed By: mweststrate
Differential Revision: D26305576
fbshipit-source-id: 90516af4e9ba8504720ddfa587f691f53e71b702
