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:
Bumps [async-mutex](https://github.com/DirtyHairy/async-mutex) from 0.2.6 to 0.3.1.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/DirtyHairy/async-mutex/blob/master/CHANGELOG.md">async-mutex's changelog</a>.</em></p>
<blockquote>
<h2>0.3.1</h2>
<ul>
<li><code>withTimeout</code>: make Jest happy and cancel timer when the mutex is acquired.
Thanks to cantoine for the PR.</li>
</ul>
<h2>0.3.0</h2>
<ul>
<li>
<p>Deprecate <code>Mutex::release</code> / <code>Semaphore::release</code> and remove them from the
documentation. The methods are still available in 0.3.x, but will be removed in
0.4.0.</p>
<p>I don't like breaking existing APIs, but using those methods is inherently
dangerous as they can accidentially release locks acquired in a completely
different place. Furthermore, they are mostly useless for semaphores. I consider
adding them an unfortunate mistake on my end.</p>
<p>A safe alternative is the usage of <code>runExclusive</code> which allows to execute
blocks exclusively and automatically manages acquiring and releasing the
mutex or semaphore.</p>
</li>
<li>
<p>Add <code>Mutex::cancel</code> / <code>Semaphore::cancel</code> for rejecting all currently pending
locks.</p>
</li>
<li>
<p>Add <code>tryAcquire</code> decorator for lock-or-fail semantics.</p>
</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="93f1ff7d6d"><code>93f1ff7</code></a> Changelog, bump version.</li>
<li><a href="3aad9351d7"><code>3aad935</code></a> Bump version.</li>
<li><a href="eed47b0425"><code>eed47b0</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/DirtyHairy/async-mutex/issues/34">https://github.com/facebook/flipper/issues/34</a> from cantoine/clear-timeout-fix</li>
<li><a href="38e59ba3b4"><code>38e59ba</code></a> Add clearTimeout and tests</li>
<li><a href="76fb6185d3"><code>76fb618</code></a> Point badge to action on gh.</li>
<li><a href="330854af56"><code>330854a</code></a> Typo.</li>
<li><a href="73992fee3a"><code>73992fe</code></a> Ups.</li>
<li><a href="b3870af6b6"><code>b3870af</code></a> Badge.</li>
<li><a href="13ad461682"><code>13ad461</code></a> Another stab at coveralls.</li>
<li><a href="3e5daebbb7"><code>3e5daeb</code></a> Remove travis, add coveralls to github workflow.</li>
<li>Additional commits viewable in <a href="https://github.com/DirtyHairy/async-mutex/compare/v0.2.6...v0.3.1">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `dependabot rebase` will rebase this PR
- `dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `dependabot merge` will merge this PR after your CI passes on it
- `dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `dependabot cancel merge` will cancel a previously requested merge and block automerging
- `dependabot reopen` will reopen this PR if it is closed
- `dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
Pull Request resolved: https://github.com/facebook/flipper/pull/1984
Reviewed By: passy
Differential Revision: D26724090
Pulled By: mweststrate
fbshipit-source-id: 71a59fe1df200198fc437d2a87f72dde82ba4fa4
Summary:
Bumps [react-color](https://github.com/casesandberg/react-color) from 2.18.1 to 2.19.3.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a href="https://github.com/casesandberg/react-color/commits">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `dependabot rebase` will rebase this PR
- `dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `dependabot merge` will merge this PR after your CI passes on it
- `dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `dependabot cancel merge` will cancel a previously requested merge and block automerging
- `dependabot reopen` will reopen this PR if it is closed
- `dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
Pull Request resolved: https://github.com/facebook/flipper/pull/1987
Reviewed By: passy
Differential Revision: D26724081
Pulled By: mweststrate
fbshipit-source-id: c7b136546206dadfbd1a793360953b14586b219b
Summary: When exploratory testing Flipper, I generally see quite some React key warnings. So it seems that plugin devs often miss them. This diff will configure linting more aggressively to address that (it's not fool proof, but will find the most common cases).
Reviewed By: nikoant
Differential Revision: D26722707
fbshipit-source-id: e0d2b56de2422e1147f52c8e9150d00c7ee64bd2
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: Gave every device an icon, and use it as fallback in case we don't have a client icon. Added an icon for the Flipper client. This gets (largely) rid of the 'blank' icons
Reviewed By: fabiomassimo
Differential Revision: D26691054
fbshipit-source-id: d83012e755ae5edb230747e88f9b2eac45450b19
Summary:
There is currently a separate device for the Flipper inspection plugin. Figured it would be simpler and more logical to directly put it under the host device.
Might clean this up further in the future by having a `host` device and turning this into a device plugin
Reviewed By: fabiomassimo
Differential Revision: D26691053
fbshipit-source-id: 4f2fe890a1fff559b19b1599cc02017c45a635b9
Summary:
Fixes https://github.com/facebook/flipper/issues/1945
Changelog: Fixed an issue where device plugins targeting the host device didn't show up without connected clients.
Reviewed By: fabiomassimo
Differential Revision: D26690516
fbshipit-source-id: b46fd9bf06189354ed772581dc8db6b17104bea9
Summary:
Fix for https://github.com/facebook/flipper/issues/1964
Changelog: fixed possible crash on startup after updating from a previous Flipper version to 0.77.0
Reviewed By: mweststrate
Differential Revision: D26664846
fbshipit-source-id: 6f9fabeaee8cfe1fa0df11bb57e27d659378a835
Summary:
Bumps [rsocket-flowable](https://github.com/rsocket/rsocket-js) from 0.0.22 to 0.0.23.
<details>
<summary>Commits</summary>
<ul>
<li><a href="8e357291ed"><code>8e35729</code></a> v0.0.23</li>
<li><a href="5eece29159"><code>5eece29</code></a> ensures existing Buffer polyfills are overridden (<a href="https://github-redirect.dependabot.com/rsocket/rsocket-js/issues/114">https://github.com/facebook/flipper/issues/114</a>)</li>
<li><a href="e002a64d69"><code>e002a64</code></a> ensures connection closed if connect() subscription is cancelled (<a href="https://github-redirect.dependabot.com/rsocket/rsocket-js/issues/113">https://github.com/facebook/flipper/issues/113</a>)</li>
<li><a href="a94ebeab5b"><code>a94ebea</code></a> improves example</li>
<li><a href="6fb2aa519b"><code>6fb2aa5</code></a> removes proper handler</li>
<li><a href="d392b39843"><code>d392b39</code></a> adds missing rsocket-types package</li>
<li><a href="f85762d078"><code>f85762d</code></a> adds example of server-side with composite metadata</li>
<li><a href="195e9affd5"><code>195e9af</code></a> fixes formats and improves composite-metadata example</li>
<li>See full diff in <a href="https://github.com/rsocket/rsocket-js/compare/v0.0.22...v0.0.23">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `dependabot rebase` will rebase this PR
- `dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `dependabot merge` will merge this PR after your CI passes on it
- `dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `dependabot cancel merge` will cancel a previously requested merge and block automerging
- `dependabot reopen` will reopen this PR if it is closed
- `dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
Pull Request resolved: https://github.com/facebook/flipper/pull/1954
Reviewed By: mweststrate
Differential Revision: D26605957
Pulled By: passy
fbshipit-source-id: 511bf81579216edc60ab4ab1f4a1adab1cd305c2
Summary:
A temporarily hack that was a left-over from the past where we could switch between Sandy and non-Sandy UI, caused Flipper to crash.
This is the first runtime crash we find with the new Crash reporting dialog last week :)
Changelog: Fixed an issue where Flipper could occasionally crash when disconnecting a device
Reviewed By: passy
Differential Revision: D26634620
fbshipit-source-id: 5ca0b14dee332859a4d8af27501f0916c55a1370
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:
Errors and warnings are both shown to users. I'm applying the rule of
thumb of using errors for non-recoverable problems that require *our*
intervention. All of these errors can happen under normal
circumstances.
Reviewed By: mweststrate
Differential Revision: D26577917
fbshipit-source-id: 12ba6725b6575bdf62141b01a16a5638c2c95701
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:
We do have a fall-back for this so there's no need to give this error or even
warning treatment. If the fallback fails, we already have a warning.
Reviewed By: mweststrate
Differential Revision: D26547277
fbshipit-source-id: 96ac91def7e6e111d32d3536d8796f347d6c519d
Summary: Keeps a small ring buffer of errors we're sending and checks if they're tracked. I'm sure there's a better data structure for this out there were we could have O(1) membership checks, but since we're not keeping that many errors to begin with and we're saving a lot of CPU that would go into sending the errors to Scribe, this should be a net positive.
Reviewed By: mweststrate
Differential Revision: D26488825
fbshipit-source-id: fdcf58e88d43864852c13e4741a7ab620d596094
Summary:
Video recording for Android devices is quite unreliable now, because not all resolutions are supported:
https://android.stackexchange.com/questions/168944/unable-to-get-output-buffers-err-38-when-attempting-to-screen-record-emulator
In this diff I changed resolution for the captured videos to always be 1280x720 or 720x1280. These resolutions are always supported because they are used by default if device native resolution cannot be detected.
Changelog: Android video is now always captured in 1280x720 / 720x1280 to avoid the issue when video cannot be captured because of unsupported resolution (err=-38)
Reviewed By: mweststrate
Differential Revision: D26225203
fbshipit-source-id: 0f9491309bf049fd975f20e096c5c7362d830adc
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:
Noticed that subsequent `adb logcat` invocations are stateful, and we didn't clear it's state when clearing the logs in memory.
This is a bandaid to get back to the previous behavior. I am wondering whether it wouldn't be just much more intuitive to always clear the logs (`adb logcat -c`) before we start the streaming log listener, so that users are never shown old logs from before flipper was connected?
Also fixed a leak in cleaning up the log listeners that was revealed by the possibility to disable the log plugin
Reviewed By: nikoant
Differential Revision: D26450262
fbshipit-source-id: 5b426e2d0e1fafdbc512d48d22b7bd4f30b61309
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: Enable device plugins by default to minimise breaking changes for users. Users will be able disable them if they want.
Reviewed By: mweststrate
Differential Revision: D26439227
fbshipit-source-id: 95c19e9335d583646c8aafd70a03e73bcf86c3bc
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
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 "load plugin" operation to perform it in pluginManager dispatcher.
Reviewed By: mweststrate
Differential Revision: D26166654
fbshipit-source-id: e1fe48fa2cfc5533ad4f801ca56f00fc2ca3f4c4
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 "uninstall plugin" operation to perform it in pluginManager dispatcher
Reviewed By: mweststrate
Differential Revision: D26166198
fbshipit-source-id: d74a1d690102d9036c6d3d8612d2428f5ecef4e6
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 Flipper mocking helpers to allow testing of plugin commands, and wrote some tests for pluginManager.
Reviewed By: mweststrate
Differential Revision: D26450344
fbshipit-source-id: 0e8414517cc1ad353781dffd7ffb4a5f9a815d38
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*: implemented basic plugin action queue processing.
Reviewed By: mweststrate
Differential Revision: D26164945
fbshipit-source-id: 5d8ad9b4d7b1300e92883d24a71da9ca1f85b183
Summary: Found some code duplication causing old devices not entirely to be cleaned up as they should
Reviewed By: nikoant
Differential Revision: D26422665
fbshipit-source-id: f57757f7260ac5de17edd80e9f66cc844d1a6213
Summary:
Changelog: Fixed issue where a Flipper crash would result in an entirely blank screen, rather than a useful error message.
While debugging another issue, discovered that React errors that happen outside a Plugin aren't caught at all, resulting in the infamous gray screen of deaths. This was the case because no error boundary has been set up for our Chrome, and since React 16 the default error handling has becoming rendering blank, rather than freezing. See https://reactjs.org/docs/error-boundaries.html#new-behavior-for-uncaught-errors.
Thanks to ant.design styling this decently was trivial :). But sadly involved a component class since error boundaries are not yet available as hook.
With these changes the errors should also end up more readably in our monitoring.
Reviewed By: nikoant
Differential Revision: D26422666
fbshipit-source-id: 6c0f8611c80a4a5e0d7e61d58afcf5eabe410e57
Summary:
T84629221 shows this is quite common and is not something we want
to log errors for.
Reviewed By: mweststrate
Differential Revision: D26371400
fbshipit-source-id: 748a83d8ad484b0ceb1f3bf7e3a447602ae4c961
Summary:
This is our #1 error and always means there's something off with
the user's setup.
Reviewed By: mweststrate
Differential Revision: D26370974
fbshipit-source-id: 5e2644ce9de8a7d28614a22fab5ce54dab0561d3
Summary:
Adding context everywhere as naked messages are hard to track down
and making common errors like missing Xcode license agreements
a warning + error popup instead.
Changelog: Reduce spamminess of iOS connection warnings
Reviewed By: mweststrate
Differential Revision: D26370235
fbshipit-source-id: b283d297479c2bf76a11b5a3f96a59fad70a4a67
Summary: Noticed in the support group that the imported device label was incorrect. Probably a copy paste error.
Reviewed By: nikoant
Differential Revision: D26368664
fbshipit-source-id: abc2aad4d20a9f44d6f1ac45962ab28863d78f0d
Summary:
I want to use TypesScipt type literals in a next diff (e.g.
```
type Percentage = `${number}%`
```
But to be able to use that typescript, prettier and eslint needed bumps :)
Reviewed By: nikoant
Differential Revision: D26321133
fbshipit-source-id: a4891246ef8c654f324c6daf303c5c4b2f54496e
Summary:
Some minor loose ends from exploratory testing:
- disconnect device logs event listeners if the device disconnects
- show metro if that is still up, even if the app is no longer connected
- hide the options in the support form to record videos / screenshots if the device isn't connected
Reviewed By: nikoant
Differential Revision: D26277100
fbshipit-source-id: 49d0c934d587b226bc25524224efce60b53939e9
Summary:
Per title, if a plugin makes a client call, show a quick notif so that the user knows why his plugin interactions aren't responding in case the plugin doesn't use `isConnected` guards.
This might turn out to be too spammy, but I think it should be ok.
Reviewed By: nikoant
Differential Revision: D26277099
fbshipit-source-id: bd555ea84acae6189ec7f8fff0fc0a088dbc5337
Summary:
Previously, plugins could relatively safely use `client.call` at any moment in time to fetch some information from / to the client. Except for some raise conditions there was generally speaking a connection available.
With this stack it becomes possible to interact with plugins even after an app (unexpectedly) disconnected, which makes Flipper a lot more versatile, especially when it comes to inspect crashes post mortem. (For more explanation see the second diff in this stack)
However, this means that it is no longer safe to assume there is always a connection available. For that reason `client.isConnected` has been introduced to safeguard against that.
This diff introduces guards on all user interactions that are not super explicitly triggered by the user to avoid a lot of errors being generated. This is mostly in `init()` blocks and implicit user events like selecting or hovering rows.
Explicit user interactions like pressing buttons are not guarded by this diff, as ideally failure to communicate with the client should be communicated back to the user more explicitly rather than failing silently. The next diff will introduce a fallback mechanism where a popup is shown in case those calls aren't guarded.
Fixed a few key warnings while at it.
Reviewed By: nikoant
Differential Revision: D26275604
fbshipit-source-id: 5630066cdd9541e448a6dd1f8a21861b5d751ced
Summary:
Minor code cleanup to avoid future confusion:
- archived: a device that was imported from a Flipper trace, and only has persisted state
- (dis)connected: a real stateful device that might or might not have an active connection
Reviewed By: nikoant
Differential Revision: D26275459
fbshipit-source-id: eba554b37c39711e367c3795ff4456329a303c22
Summary:
This diff addresses two problems:
1. Since clients plugins can be active beyond having a connection, we have to make it possible for plugin authors to check if they are connected before they make a call.
2. if there is a custom `exportPersistedState`, plugins should be able to skip making calls if the device has disconnected.
Introducing this change makes it possible to interact with a reasonable level with disconnected clients, and makes it possible to create Flipper traces for disconnected clients.
Note that both items were already problems before supporting offline clients; as there can be a noticeable delay between disconnecting and Flipper detecting that (i've seen up to 30 secs). What happend previously in those cases is that the export would simply hang, as would other user interactions, as loosing the connection in the middle of a process would cause the promise chains to be neither rejected or resolved, which is pretty iffy.
Before this diff, trying to export a disconnected device would hang forever like:
{F369600601}
Reviewed By: nikoant
Differential Revision: D26250895
fbshipit-source-id: 177624a116883c3cba14390cd0fe164e243bb97c
Summary:
During testing I noticed that even though plugin queues were flushed, the processed messages didn't end up in the export snapshots. This was caused by holding a ref of an older snapshot of the state
Changelog: Fixed an issue where data that arrived in the background was not part of the generated Flipper export.
Reviewed By: nikoant
Differential Revision: D26250897
fbshipit-source-id: ddd3f5bb19e38a1b13498d03f235bf63858eb8f8
