Summary: This diff updates the device display name in the drop down for DummyDevice
Reviewed By: mweststrate
Differential Revision: D26945724
fbshipit-source-id: 6a82c6353f6d8dfe6d3a60e06f0f78d00c39ff59
Summary: Rename ClientDevice to DummyDevice. It is being currently used in the case when we do cert exchange through WWW/Distillery. In this mode we are not able to figure out the exact device id(instead we create a fake one) and thus we would not like to use Android or IOSDevice for such cases.
Reviewed By: mweststrate
Differential Revision: D26944415
fbshipit-source-id: f9f76e8997cf5402ba5627ae1959f5a11e078bb1
Summary: Create a constant to hold all valid origin prefixes, for incoming WebSocket requests. This is to make it easier to add additional origins.
Reviewed By: mweststrate
Differential Revision: D26778708
fbshipit-source-id: b89bd8c8d8925b2863f12c319c6ecbeeb265fc42
Summary:
Packaged KaiOS apps have "app://" as their origin prefix (see the "origin" section in the documentation - https://developer.kaiostech.com/getting-started/main-concepts/manifest).
Accept WebSocket connections from any "app://" origin, so can connect to Flipper from apps running on KaiOS devices.
Reviewed By: priteshrnandgaonkar
Differential Revision: D26728925
fbshipit-source-id: 05f15fe464bf0dc977665fba1dd2b8d61a399fa6
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:
This diff introduces support for keeping clients around after they have disconnected. This is a pretty important debugging improvement, that will allow inspecting a device / app after it crashed for example.
With this diff, the current client is just kept around until it connects again, instead of throwing clients immediately away if they disconnect. After this change, ArchivedClients will only be created by imports / exports, and no longer by disconnects. Initially I played with improving the creation of archived devices, by migrating all plugin state over from the original client to the archive, but I discovered that is very prone, as it would be a lot of pointer redistribution (plugins would point to a different client / device etc). While in contrast, disconnected clients is already an existing concept in Flipper, so reusing that keeps all the changes relatively simple.
Note that we could potentially still reuse old clients around after reconnected, but it would become much harder to reason about how plugins would behave if they missed updates for a while, so throwing away the device / clients and starting with a fresh slate sounds safer. So I figured that chance to be too risky for now, but would probably be good follow up work.
Issues with import / export, UX, and making calls to to a disconnected client will be addressed in follow up diffs
Changelog: Clients will retain their state after being disconnected, until they reconnect again
Reviewed By: nikoant
Differential Revision: D26224677
fbshipit-source-id: feb9d241df2304341c2847fe7fd751ac54c045f6
Summary:
devices not always being readily available is causes a lot of complication in the api,
figured to resolve devices first before construction clients,
since clients not attached to a device are shown uncategorized anyway, making them practically un-interactable.
For more background info, see following chat.
{F344388883}
This diff will make it possible to only expose a synchronous api in Sandy
n.b. didn't update Navigation plugin, as that is done in a next diff
Reviewed By: jknoxville
Differential Revision: D24858332
fbshipit-source-id: 8339f831fbbc9c219add56a199364fde67adafc7
Summary:
I noticed that after the typescript upgrade, I got several weird positives from ESLint (like unused parameters in a type definition, which are obviously always unused, e.g. `type onClick = (e: Event) => void`). After some investigation, it turned out these warnings are generated by eslint, but that those rules should be performaned by typescript/eslint instead. For future reference to which rules this applies:
https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/README.md#extension-rules
Updated the config, and while at it, fixed all warnings in our codebase, except for `react-hooks/exhaustive-deps` warnings, since those require semantic changes.
This reduces the amount of eslint warnings from 86 to 39.
Reviewed By: passy
Differential Revision: D23905630
fbshipit-source-id: 0557708fd9ec6b17840a3c191e7d3baf225bdf23
Summary:
we used to send plugins list with connect command, now we can respond to getPlugins request with new api.
we still support old clients
Reviewed By: jknoxville
Differential Revision: D23625139
fbshipit-source-id: 37a24d0c83cd879d93287dd3a3d4d5d2f9477b34
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: This diff fires a notification with a remediation suggestion when the client takes a long time to connect back, for both WW and FS_ACCESS case
Reviewed By: mweststrate
Differential Revision: D23321067
fbshipit-source-id: 17ab93974e9571a0ba78af05c624eeb0522637c6
Summary:
Flipper self inspection is being used by internal devs for a month now and peeple seems happy with it :) Let's make it available to open source devs!
changelog: Flipper Self inspection - Flipper Messages plugin added to dev builds to show messages sent/received from clients
Reviewed By: jknoxville
Differential Revision: D23345560
fbshipit-source-id: 95bac52b966a78fbfa8e4d4c4e15d9d45ca960f7
Summary: With this change, I verified that our enterprise wilde app is able to connect to Flipper.
Reviewed By: jknoxville
Differential Revision: D23318335
fbshipit-source-id: cc952297ead1e8afcb1d9f5062e593e51e8ce893
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:
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:
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 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:
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: Missed an else on the if statement, causing it to duplicate websocket messages.
Reviewed By: passy
Differential Revision: D21256794
fbshipit-source-id: ea4abb88723a052a3490b930420ee6b005447c81
Summary:
The websocket server has a race condition where it only starts listening for messages after the client has finished setting up.
This lets it queue up messages if the client isn't ready.
Reviewed By: passy
Differential Revision: D21256218
fbshipit-source-id: fa8481e11225cc473f03f3afbf4d0c50a48cec91
Summary: I think it is good to have error handlers where-ever possible, so that there is historical data in our monitoring when we need it, and can track from which point of the code it originates :)
Reviewed By: jknoxville
Differential Revision: D21040059
fbshipit-source-id: 1c07fbfa65379739554bc98f83761ae97870ba82
Summary: Unity is using this, and I noticed it was showing up as Web Browser which is a bit misleading.
Differential Revision: D21067698
fbshipit-source-id: 93d6a598824e61490e0eadd1b2c9fb3ebc12d01c
Summary: Accept websocket connections from any localhost origin, in addition to the existing chrome extensions support.
Reviewed By: jknoxville
Differential Revision: D20792131
fbshipit-source-id: d3991aa375bfb4e6f492c02dfab9bf72b1f8c412
Summary: Import ws package in a usual way instead of importing it as source code
Reviewed By: jknoxville
Differential Revision: D20724584
fbshipit-source-id: 39cad6e544b71e66560a9351f1e5a0c89be2c152
Summary:
Quick notes:
- This looks worse than it is. It adds mandatory parentheses to single argument lambdas. Lots of outrage on Twitter about it, personally I'm {emoji:1f937_200d_2642} about it.
- Space before function, e.g. `a = function ()` is now enforced. I like this because both were fine before.
- I added `eslint-config-prettier` to the config because otherwise a ton of rules conflict with eslint itself.
Close https://github.com/facebook/flipper/pull/915
Reviewed By: jknoxville
Differential Revision: D20594929
fbshipit-source-id: ca1c65376b90e009550dd6d1f4e0831d32cbff03
Summary:
Our usage of requestIdleCallback (probably) causes more trouble than it solves:
1. It makes sure everything is processed asynchronously. But since everything is arriving over a network stack, that is already the case without wrapping it again to run on a separate event loop tick
2. The timeout we set before `500` forces the app to give _more_ priority to message processing instead of less
3. In a next diff (D20151700) in this stack we will make sure that messages are not processed immediately, but simple stored, which should not be significantly more expensive (probably even cheaper) than scheduling another tick on the event loop
Reviewed By: jknoxville
Differential Revision: D20557104
fbshipit-source-id: 6cc10ba537e3cb5f31e6c32e1fdeb57c20f06f17
Summary:
1) moved "sonar/desktop/src" to "sonar/desktop/app/src", so "app" is now a separate package containing the core Flipper app code
2) Configured yarn workspaces with the root in "sonar/desktop": app, static, pkg, doctor, headless-tests. Plugins are not included for now, I plan to do this later.
Reviewed By: jknoxville
Differential Revision: D20535782
fbshipit-source-id: 600b2301960f37c7d72166e0d04eba462bec9fc1
