See D23051239
Since the crash reporter endpoint does not exist anymore, and no data was reported there, removing the corresponding code from Flipper as well.
This also fixes the last remaining startup warning as well :)
Reviewed By: priteshrnandgaonkar
Differential Revision: D23472612
fbshipit-source-id: 7ce9f6a0261cdfe197a7da9b28a86407299effec
Summary: This diff adds analytics for events like uploading certs, zipping certs.Also logs the payload data received in trusted and untrusted request handlers. It will be helpful to debug the issues through this events.
Reviewed By: jknoxville
Differential Revision: D23374024
fbshipit-source-id: 6fa709bbf05e1b99ed1882be953abbd968eefc6e
Summary:
Bringing the pkd CPU usage fix to open source releases.
Now when idb is installed, Flipper will always use it to check for devices, and only fallback to instruments if not.
Fixes https://github.com/facebook/flipper/issues/1028
Reviewed By: passy
Differential Revision: D23293675
fbshipit-source-id: 6ff3e89167f5f6d4130f197b2a675202334d0e7d
Summary:
Some non-semantic changes. Mostly an earlier rename that was accidentally done only locally rather than across the codebase
Also support `.spec` test extension, which is more idiomatic Jest, since we don't use the `.node` and `.electron` distinction anymore anyway.
Reviewed By: jknoxville
Differential Revision: D22976438
fbshipit-source-id: f3abedb36cbac1e835295177117ccbca492a67a1
Summary:
As per the title
Bug:
{F288338655}
Reviewed By: mweststrate
Differential Revision: D23168390
fbshipit-source-id: e57ac1f22c0a3932fe9948d16cf9fc9cc74ab636
Summary:
This diff adds upload and download logic for certs. It makes changes on both Flipper Client and Desktop side. With this we enable cert exchange through WWW.
Next Diffs:
1) Add Flipper state in cert provider for more debug data
2) Tests
Reviewed By: jknoxville
Differential Revision: D23092706
fbshipit-source-id: e576253606b64b62848b70203db7e09a3bd77fd9
Summary:
Running `instruments -s devices` causes the `pkd` process in catalina to spike to ~100% for a few seconds.
Flipper runs this command every 3 seconds to poll for devices.
This switches it to use `idb list-targets` instead which is much more performant.
Currently switched off in the open-source version while we make sure it's working well. If you set the GK value 'flipper_use_idb_to_list_devices' to true, then you'll get the new behaviour.
Reviewed By: passy
Differential Revision: D23102067
fbshipit-source-id: 9e17155d938a4fe326e082511f747444e4b533a2
Summary:
This diff adds a toggle setting in wilde which will enable certificate exchange through www.
Right now it just sends the information about which medium to be used for cert exchange to Flipper JS and its client side. But its implementation is not done yet.
### Flow for Wilde
Whenever user changes the setting(or when user logs out) we set the state of exchange medium and accordingly set/reset authtoken. Note at no given point we remove already existing certificates.
### Context for OSS
With this diff we introduce another way to do certificate exchange. Before this diff, we did certificate exchange by accessing the file system of app. But it turns out it's not possible to do that in applications signed by enterprise certs. Thus with this diff one can write their FlipperKitCertificateProvider and fetch the certificate from WWW.
Reviewed By: jknoxville
Differential Revision: D22896320
fbshipit-source-id: 55aef7028a62e71ba9c02f9f79acaab41d09c0c6
Summary: This is tanking our success rates, but is an expected behaviour.
Reviewed By: jknoxville
Differential Revision: D23001697
fbshipit-source-id: 48bcdb99543d590d544cce8322950568a0ef5c6f
Summary:
Added support for `createPaste` in Sandy plugins
Nice minimalistic example of how to expose a Flipper api to Sandy.
Note that some indirection could be removed by having an interface that is shared directly between `BasePluginClient` and `FlipperLib` (e.g. `PublicFlipperLib`). In contrast to `addMenuEntries` from the previous diff, `createPaste` is basically exposed verbatim to Sandy without additional wrapping, so those cases could be made simpler. Maybe will do that later.
Reviewed By: passy
Differential Revision: D22815873
fbshipit-source-id: e6d0773a35341edfe5de0898317eaadf88de79d0
Summary:
[interesting] since it shows how Flipper APIs are exposed through sandy. However, the next diff is a much simpler example of that
This diff adds support for adding menu entries for sandy plugin (renamed keyboard actions to menus, as it always creates a menu entry, but not necessarily a keyboard shortcut)
```
client.addMenuEntry(
// custom entry
{
label: 'Reset Selection',
topLevelMenu: 'Edit',
handler: () => {
selectedID.set(null);
},
},
// based on built-in action (sets standard label, shortcut)
{
action: 'createPaste',
handler: () => {
console.log('creating paste');
},
},
);
```
Most of this diff is introducing the concept of FlipperUtils, a set of static Flipper methods (not related to a device or client) that can be used from Sandy. This will for example be used to implement things as `createPaste` as well
Reviewed By: nikoant
Differential Revision: D22766990
fbshipit-source-id: ce90af3b700e6c3d9a779a3bab4673ba356f3933
Summary:
The device type enum was mixing two different concepts (emulator vs physical) and (archived vs not), and we already have a separate `isArchived` field. So cleaned this up to not leak it into sandy.
If anybody can think of any unforeseen consequences of this, lemme know :)
Reviewed By: jknoxville
Differential Revision: D22763506
fbshipit-source-id: bd2f7dbd1d2d2e6942ba7c6ddd8dc91ee34d591d
Summary: Introducing a base abstract class (blegh) to share some life cycle management between Device- and normal plugins. Cleaned up the test utils a bit as well + some old TODO's that now have been taken care of
Reviewed By: nikoant
Differential Revision: D22727089
fbshipit-source-id: 507816f1bfdbc6e7e71d4bd365b881b6710ca917
Summary:
This diff makes sure that devices will actually instantiate applicable sandy device plugins. Similar to how client plugins are owned by Client, device plugins are directly owned by BaseDevice, which significantly simplifies life cycle management and doesn't dispatch updates to all Redux connect components whenever something irrelevant changes.
Also made sure `device.teardown()` is called. That API already existed, but wasn't used or implemented before.
Updated Flipper test utils to support testing device plugins as well (both Sandy and classic ones)
Reviewed By: passy, nikoant
Differential Revision: D22693929
fbshipit-source-id: 73b2b8666ef7a0e748ea89360db84734d37eb5be
Summary:
This stack introduces Sandy device plugins, they are quite similar to normal plugins, but, a devicePlugin module is organized as
```
export function supportsDevice(device): boolean
export function devicePlugin(devicePluginClient)
export function Component
```
Device plugins get access to the device meta data and can subscribe to the `onLogEntry` callback and `onDestroy` lifecycle.
They will be able to store state just as normal plugins, but can't send or receive methods, so devicePluginClient is a bit limited.
This diff only sets up most of the new data structures, and makes sure everything still compiles and no existing tests fail.
To prevent this diff from becoming to big, actually loading, rendering and testing device plugins will be done in next diffs
Please take a critical look at the api proposed and the (especially) the public names used :)
Reviewed By: passy, nikoant
Differential Revision: D22691351
fbshipit-source-id: bdbbd7f86d14b646fc9a693ad19f33583a76f26d
Summary:
The current Popover component isn't compatible with the new (in progress) component library because it relies on overflowing container elements, which isn't allowed in the generic Layout component.
So this is a new Popover element, which uses absolute positioning instead. It takes heavy inspiration from the Tooltip and TooltipProvider components which do a similar thing.
Still to do:
[x] Edge cases when popover would be near a window edge
[x] Style it to look nice
[x] Split the use case (RatingButton) changes into a separate diff
[x] When the location of the popover container moves (the rating button in this case, e.g. if you resize the window), it doesn't currently cause the effect function in the popover, so it doesn't get moved when it should
[x] Add a little pointer thingy like a speech bubble
[x] Make sure it's perfectly positioned
[ ] Rename it to Popover and delete the old one. Not done, since it's just a stopgap.
Reviewed By: mweststrate
Differential Revision: D22693105
fbshipit-source-id: bc141433914bc20da48f8ae96764a95f7cd74ce5
Summary:
let's finally inspect flipper with flipper!
Here we have:
1) a self inspection client which implements FlipperClient interface from js sdk and FlipperClientConnection. It links back and front parts of self inspection
2) simple plugin (UI) to show messages
3) back part of that plugin - it sends all received messages to UI part via client
4) we initialize self inspection for dev builds only
P. S. filesystem dependency will be replaced with npm one before I ship it (need to publish to npm first)
Reviewed By: mweststrate
Differential Revision: D22524533
fbshipit-source-id: 5c77e2f7b50e24ff7314e791a4dfe3c349dccdee
Summary:
This diff makes sure Sandy plugins show up as well in the plugin selector when making exports (and in support form as well).
Also verified that this works with the Sandy updated section plugin.
Note that persisted state now didn't need any changes in the plugin code to work :)
Commented / simplified the calculation of available plugins a little bit and fixed a confusing issue where two different redux stores where created in one unit test, which caused an issue in the new implementation.
Reviewed By: jknoxville
Differential Revision: D22434301
fbshipit-source-id: c911196bc5b105309e82204188f124f40aab487a
Summary:
Made Sandy plugins part of the export / import logic
Note that in the export format there is now a `pluginStates2` field. It could have been put in `pluginStates` as well, but I started with that and it felt very weird, as the `pluginStates` are supposed to reflect what is living in the Redux stores, where sandy state doesn't live in the Redux store (not directly at least). Trying to store it in the same field made things overcomplicated and confusing.
Reviewed By: jknoxville
Differential Revision: D22432769
fbshipit-source-id: d9858e561fad4fadbf0f90858874ed444e3a836c
Summary:
This plugin adds serialization capabilities to Sandy plugins buy setting the a `persist: <key>` flag. This shouldn't be used for state that is unserializable, too big, too sensitive, or irrelevant during export / import.
Using an explicit `persist` flag is done to make plugins robust to changes over time; as long as the key is kept the same, state variables can be renamed and reordered without breaking the import / export format. Also it allows us to detect some changes in the import / export format and warn about it.
Alternative designs considered but not implemented would be:
1. requiring the user to explicitly return the state from the factory (e.g. `const todos = createState([]); return { todos }`,
2. or construct the state from client (e.g. `const todos = client.createState([])`)
3. enable persistence by default, and store states in the order the states were created (much like useState in React). This was implemented in the first versions of this diff, but as pointed out in the discussions, this is too sensitive too (accidental) format changes, as the storage format would be quite implicit
A nice benefit of the current approach, especially compared with alternative approach 1, is that state being restored is immediately visible in the plugin factory. In other words, directly after initialization `const todos = createState([])`, the `todos.get()` is actually set to the state that is being restored, rather than having still the initial state which is only overridden rather. So this behaves very much like the `useState` hook in React.
Furthermore, in the future we could use the same `persist` key in combination with other options, such as `saveToLocalStorage`, in case some state acts as a 'preference' (T69989583).
`TestUtils.startPlugin` supports starting plugins with an initial state by using the optional `initialState` field
Actually wiring up the serialization and deserialization into the export / import functionality of Flipper is done in the next diff.
Reviewed By: jknoxville
Differential Revision: D22432770
fbshipit-source-id: 9a4849582c2f6f54d1e40f65a6cba73092c28fe8
Summary:
Turns out, we don't have any tests that _actually_ depend on Electron. What is more, the one test suite that was still left was actually failing for a long time, but somehow CI didn't pick and reported that :-P.
Note that I dropped the file `xplat/sonar/scripts/facebook/lego/run-sc-yarn-targets-with-electron.sh` entirely, as it appeared unused
Reviewed By: nikoant
Differential Revision: D22434441
fbshipit-source-id: 34df79a580a64904116ae93069bbc8fafc53d9d0
Summary:
While writing unit tests discovered a bug that disabling a plugin doesn't guarantee cleaning the messagequeues (both the buffer in client and the messagequeue reducer).
Fixed that. That was thanks to @#%@#$@#%@ Redux a lot harder than it should be; as 'STAR_PLUGIN' reasons about a plugin + app name, while the message queue reducer would need to deduct the plugin keys from that, but it can't because that mapping is stored in the connections reducers. So I moved the `STAR_PLUGIN` action handling to the root reducer, sot that it can reason about the state of multiple reducers, which looked like the least of all evils. For more ranting about that and possible alternative solutions: https://twitter.com/mweststrate/status/1277556309706117122
Reviewed By: nikoant
Differential Revision: D22284043
fbshipit-source-id: 35d0a8ba3a21a5959d2bb6ef17da3ff5077f48fd
Summary: This diffs adds the capability to listen to messages in Sandy plugins. Although API wise it looks more like the old `this.subscribe`, semantically it behaves like the `persistedStateReducer`; messages are queued if the plugin is enabled but not active.
Reviewed By: nikoant
Differential Revision: D22282711
fbshipit-source-id: 885faa702fe779ac8d593c1d224b2be13e688d47
Summary: Really nothing interesting to see here , just moved pluginStats out of messageQueue, as it started there and kept growing
Reviewed By: nikoant
Differential Revision: D22257318
fbshipit-source-id: 26be7efb4629fcef1b14de96a2b60f17f7d76785
Summary:
When running unit tests, every unit would try to make a graphql request (since promises always kick off immediately, even when not being awaited) and print an error. Fixed that by lazily choosing the preferred whatever it is.
Before:
{F241368814}
After:
(crickets)
Reviewed By: passy
Differential Revision: D22208422
fbshipit-source-id: b290d528d94dbed7ae867e07694d8d4cd85d8376
Summary: Replaced `instanceof` checks with `isSandyPlugin` utility. That is cleaner to read and makes it easier to find places where we make exceptions for Sandy plugins
Reviewed By: jknoxville
Differential Revision: D22206707
fbshipit-source-id: b44a1b585424f3b9bf0d7ce200c34107f03ed55e
Summary:
This diff makes sure sandy plugins are initialized.
Sandy plugins are stored directly in the client for two reasons
1. we want to decouple any plugin state updates from our central redux store, as redux is particularly bad in handling high frequency updates.
2. The lifecycle of a plugin is now bound to the lifecycle of a client. This means that we don't need 'persistedStore' to make sure state is preserved; that is now the default. Switching plugins will no longer reinitialize them (but only run specific hooks, see later diffs).
3. PersistedState will be introduced for sandy plugins as well later, but primarily for import / export / debug reasons.
A significant difference with the current persistent state, is that if a client crashes and reconnects, plugins will loose their state. We can prevent this (again, since state persisting will be reintroduced), but I'm not sure we need that for the specific reconnect scenario. Because
1. we should fix reconnecting clients anyway, and from stats it looks to happen less already
2. reconnects are usually caused by plugins that aggregate a lot of data and get slower over time. Restoring old state also restores those unstabilites.
For the overview bringing back the archi picture of earlier diff:
{F241508042}
Also fixed a bug where enabling background plugins didn't enable them on all devices with that app.
Reviewed By: jknoxville
Differential Revision: D22186276
fbshipit-source-id: 3fd42b577f86920e5280aa8cce1a0bc4d5564ed9
Summary: Unit tests tend to randomly bail out once FBLogger is (indirectly) required by some module under test. This makes sure FBLogger is stubbed by default. We might want to do the same for `User` in the future.
Reviewed By: jknoxville
Differential Revision: D22186274
fbshipit-source-id: 2ede364c4b691d69826781355592226b075d8367
Summary: The test mock utilities now return a promise, rather than taking a callback, which makes tests slightly nicer to read (similar to react-testing-library). No semantic changes.
Reviewed By: jknoxville
Differential Revision: D22186278
fbshipit-source-id: ec5b9f4e6bfeee9160e331f8c20a1d4fdcbfeede
Summary:
So far there were 2 types of plugins: `FlipperPlugin` and `FlipperDevicePlugin`. This introduces a third kind: `SandyPluginDefinition`.
Unlike with the old plugins, the export of the module is not directly exposed as the plugin definition. Rather, we use class `SandyPluginDefinition` (instance) that holds a loaded definition and its meta data separately (`PluginDetails`). This means that we don't have to mix in and mutate loaded definitions, and that for unit tests we can avoid needing to provide a bunch of meta data. This also prevents a bunch of meta data existing on two places: on the loaded classes as static fields, and in the meta data field of the loaded class as well. Finally, we can now freely extends the `PluginDetails` interface in flipper, without needing to store it on the loaded classes and we are sure that no naming conflicts are caused by this in the future.
For compatibility with the existing code base, common fields are delegated from the `SandyPluginDefinition` class to the meta data.
Also cleaned up types around plugins a little bit and removed some unnecessary casts.
For all features that reason about plugins in general (such as exports), sandy plugins are ignored for now.
`SandyPluginInstance` is worked out in further diffs
The `instanceof` calls are replaced by a utility function in later diffs.
{F241363645}
Reviewed By: jknoxville
Differential Revision: D22091432
fbshipit-source-id: 3aa6b12fda5925268913779f3c3c9e84494438f8
Summary: This diff enables the installation for iOS simulators. This also fixes the error view created when there is an error. Right now there is a bug on my machine where idb doesn't detect my physical device. But once it is detected, it will work.
Reviewed By: mweststrate
Differential Revision: D22137831
fbshipit-source-id: b6d6f77318c6baef78c35af73db3969b7dd1b907
Summary:
Well this is embarassing. My iPhone is called iPhone, so I assumed instruments always outputs "iPhone" for iPhones, but it doesn't if they've got a different name.
Pointed out in https://github.com/facebook/flipper/issues/262
Reviewed By: nikoant
Differential Revision: D22066872
fbshipit-source-id: 847e1baf28103692dc9472d9730b6384ec719be0
Summary:
App Names can contain special characters. Escape them (and unescape later) so that device ID strings don't break.
Simpler is better - thanks to mweststrate for keeping me out of the rabbit hole
## Changelog
Escape app name to account for special characters in name
Pull Request resolved: https://github.com/facebook/flipper/pull/1268
Test Plan:
Added test to test character escaping: `cd desktop && yarn test -- -i app/src/utils/__tests__/clientUtils.node.tsx`
closes https://github.com/facebook/flipper/issues/1252
Reviewed By: passy
Differential Revision: D22066263
Pulled By: jknoxville
fbshipit-source-id: c820d055700ca6f55d35265528ce874eeb159216
Summary:
JS/TS api:
- migrate to TS
- some refactoring (get rid of bridge, make client abstract)
Implementation isn't full yet, things to be implemented:
- let plugins connect on init command from Flipper
- implement Responder
Further plans:
- make fully compatible with react-native api without breaking changes
Reviewed By: mweststrate
Differential Revision: D21839377
fbshipit-source-id: 9e9fe4ad01632f958b59eb255c703c6cbc5fafe2
Summary:
Adds a check for idb to flipper-doctor.
This depends on the flipper settings, to know where to look for idb, so I've made it so you can pass settings into the doctor when running it. When run from the command line, you don't get the settings. This is because settings loading currently depends on redux so I haven't extracted it into its own package.
Not that this will notify ALL open source iOS users with a doctor warning because they don't have idb installed. The error message says you can disable it in settings, which will silence this warning.
CHANGELOG: The open source version now works with physical iOS devices.
Reviewed By: passy
Differential Revision: D21883086
fbshipit-source-id: f28c43487e88a6c07ef3cc3da2764026726c9f18
Summary:
If the analytics plugin was in the foreground, and messages arrived in quick succession, some messages would not be processed.
Although the code was tested, there were not enough assertions to make sure the loop was correct. coverage !== correctness {emoji:1f605}
This fixes T68101450
Changelog: Fixed regression where analytics messages where lost
Reviewed By: jknoxville
Differential Revision: D21929679
fbshipit-source-id: c9fe2b18a249e40085d99914a809abf14fa7cf8f
Summary: Use interface PluginDetails everywhere where plugins are handled and removed PluginDefinition type which was effectively a subset of PluginDetails
Reviewed By: mweststrate
Differential Revision: D21927456
fbshipit-source-id: 434ebeef955b922cc11757e78fbba8dec05f1060
Summary: Moved plugin installation utilities to "plugin-lib" module. There are no functional changes in this diff, just refactoring so that plugin installation utils can be re-used by different modules.
Reviewed By: passy
Differential Revision: D21927387
fbshipit-source-id: 340516a544f7cfdcc15d94660dcb74a012054531
Summary:
See previous diff, let's store the collapsed state of sidebar sections in local storage.
Introduced a reusable hook to take care of that.
Changelog: Device plugins are now expanded by default, and the expand / collapse state will now be remembered across restarts
Reviewed By: passy
Differential Revision: D21903394
fbshipit-source-id: a3c0231acc0aa0877522ec328eedd09cb11aedb1
Summary:
Part of https://github.com/facebook/flipper/issues/262
Use the user-configured idb install location instead of a hardcoded one.
Reviewed By: passy
Differential Revision: D21860236
fbshipit-source-id: 5c604d7b6361e7c93ab49d8a03a437dfce880ac1
Summary:
See previous diff.
Achieves the same optimization as in the mentioned diff, but this time by only debouncing the messages as they arrive over the socket, and not the state updates caused by Redux directly. This means that plugin rendering won't be debounced anymore until we address this more fundamentally.
With this change there is a double level buffering:
1. A buffer that stores all incoming messages (that are not replies to requests)
2. A buffer that stores messages we are interested in in the plugin queue, unless the plugin is active (this we already had).
This still fixes the issue that too chatty plugins cause to many updates foreground plugin (the problem we tried to fix originally), without debouncing plugin rendering if it is needed to update for any other reason.
Another nice benefit is that previously every received message would trigger a store update in Redux which would cause all connected components to evaluate their subscriptions (and then bail out in the typical case). Now we will only update the redux store every 200 ms.
Changelog: Foreground plugins will burn less CPU when they're very chatty
Reviewed By: jknoxville
Differential Revision: D21858849
fbshipit-source-id: c72352e569a8a803bbedffb71b17b11fcefee043
Summary:
I've outlined the tasks required to get iOS device support working for open source users [here](https://github.com/facebook/flipper/issues/262).
This is the first step. It publishes the same code we use internally to GitHub, but in a state where it is only "available" for non-public builds. This will not change any behavior, but means that together with the community, we can start adapting it to suit everyone, and then eventually flip "available" to true for everyone.
Reviewed By: passy
Differential Revision: D21740193
fbshipit-source-id: 586c79ad850f67da330c10a007605ff25a187544
