Summary:
https://fb.workplace.com/groups/flippersupport/permalink/1304868459993809/
Changelog: Don't show errors for clients that fail to connect in a timely fashion repeatedly.
I think this change is fine, as even once the error is supressed, the clients will show up as 'still connecting...' in the app selector dropdown, which gives the same signal, but a bit less in the face.
Reviewed By: lawrencelomax
Differential Revision: D33976460
fbshipit-source-id: 7c5a02f3cd645ed1cbda47d186798857a05906f1
Summary:
Noticed in https://fb.workplace.com/groups/flippersupport/permalink/1305583723255616/ that always shows at the end of the plugin list.
Fixed this on two levels:
1. uppercase the title for consistency
2. Make sorting case insensitive
Differential Revision: D33985518
fbshipit-source-id: 70bed519e1ae5b3251b103931472844b2b55a512
Summary: The `Error: Attempted to build clientId with invalid app: "` event shows up in our monitoring regularly, but it is unclear which kind of app is trying to connect, so adding some more info to the error, to be able to pin point it better a next time
Reviewed By: lawrencelomax
Differential Revision: D33982871
fbshipit-source-id: 34c2612a9fe86a6815f1cc655f6def1f734e4b1e
Summary:
Our existing `timeout` implementation was always throwing an exception, due to sleeping and then throw an exception, which is than handled but ignored by `Promise.race`.
This implementation has a few problems
1. Because it always throws, having a debugger session with 'break on caught exceptions' will pause on every usage of timeout (rather than just the ones that actually timeout). This makes this way of debugging a bit useless.
2. Throwing exceptions is in principle an expensive process (due to the stack trace generation)
3. Not cancelling the timeout used by sleep is a bit of a waste as well
Reviewed By: lawrencelomax
Differential Revision: D33982717
fbshipit-source-id: d739c02112e1c1bc4cd691af852371d08a99abc6
Summary:
"Watchman not in PATH" shows up in our error monitoring, because the underlying implementation first logs an error, and then throw it (which we properly catch).
So patch-package once again to the rescue to make sure we don't error log an error we actually handle.
Reviewed By: antonk52
Differential Revision: D33982047
fbshipit-source-id: 64384b034b1991e30b2651b3ebf66cd26d519edc
Summary: From stack trace seems that we don't always get columns from the plugin, in which case we can't display anything
Reviewed By: lawrencelomax
Differential Revision: D33981285
fbshipit-source-id: 0d6bf2d9364f7dac93e2179e372308da51699bd3
Summary: Look up for the path of the adb may sometimes fail when looking for the folder platform-tools because the adb configuration wasn't done by android studio
Reviewed By: aigoncharov
Differential Revision: D33888687
fbshipit-source-id: 4d0cad2f6b19717e45422632f5d459813a7b7ee0
Summary:
This PR fixes the missing hover effect for the `LeftRail` component buttons, when they have included the badge.
To fix the issue, I had to wrap the whole `Button` with `Badge` component (instead wrapping only around icon). However, this solution required to added `offset` property to the `Badge` which moves the indicator to the position prior change (otherwise indicator was moved to the right corner of the button).
The file has been formatted after the changes with ESLint.
**Edit:** I have also spotted that this change fixes the icon placement inside the button, when badge is present. Earlier, as seen below, the log icon was moved towards the top of the button:
<img width="111" alt="Screenshot 2022-01-31 at 00 57 49" src="https://user-images.githubusercontent.com/719641/151723422-0ffb83ee-5806-412e-9191-f9953f78532e.png">
## Changelog
[desktop] UI: fix hover effect of LeftRail icons with badge
Pull Request resolved: https://github.com/facebook/flipper/pull/3372
Test Plan:
The change has been testes by running the desktop Flipper app locally from source.
## Preview (before & after)
#### Before
<img width="1339" alt="Screenshot 2022-01-31 at 00 24 23" src="https://user-images.githubusercontent.com/719641/151722800-a2f3dd44-aa24-4858-b43e-0620b1f2ae65.png">
#### After
> I have used mocked indicator values locally to ensure that the Badges are displayed correctly.
<img width="1339" alt="Screenshot 2022-01-31 at 00 26 10" src="https://user-images.githubusercontent.com/719641/151722795-745b04ac-9ee4-49a8-8217-206d8d7456e6.png">
<img width="1339" alt="Screenshot 2022-01-31 at 00 45 08" src="https://user-images.githubusercontent.com/719641/151722940-aaaf0e9b-f2d1-4245-8b2b-cfc11052b39e.png">
Reviewed By: aigoncharov
Differential Revision: D33975324
Pulled By: mweststrate
fbshipit-source-id: fe4773b4825b9f22e01821e45259747d319233aa
Summary:
When connection to Android, I always get an error popup with 'device still authorizing', which disappears itself and the device connects fine. It seems that this was a case we handled gracefully before, but the error message we check for has changed. Also updated the log message so that we get it in our monitoring I don't silently get stuck in this state.
Changelog: Fixed 'device still authorizing' errors showing up while connecting to an Android device
Reviewed By: aigoncharov
Differential Revision: D33976028
fbshipit-source-id: dbb055bbbd43bad129b10ffee4a8dbb50be8e87a
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/3394
This diff caused OSS builds failing due to a FB plugin that requires emotion, instead of using it as peer dep. This introduced a duplicate dep, which doesn't get installed in OSS, causing patch-package for that package to fail. Changed it to a peer dep and removed the patch.
Reviewed By: aigoncharov
Differential Revision: D33975202
fbshipit-source-id: 1e82964988e944a28ecb46a10127ad9e13f743f7
Summary:
Bumps [adobe/node-fetch-retry](https://github.com/adobe/node-fetch-retry) from 2.0.0 to 2.1.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/adobe/node-fetch-retry/releases"><code>@adobe/node-fetch-retry</code>'s releases</a>.</em></p>
<blockquote>
<h2>v2.1.0</h2>
<h1><a href="https://github.com/adobe/node-fetch-retry/compare/v2.0.0...v2.1.0">2.1.0</a> (2022-01-24)</h1>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="aaf1b7195d"><code>aaf1b71</code></a> [ci skip] no-release: version number update</li>
<li><a href="24d20a624b"><code>24d20a6</code></a> FEATURE-RELEASE: Add Typescript declarations (<a href="https://github-redirect.dependabot.com/adobe/node-fetch-retry/issues/42">https://github.com/facebook/flipper/issues/42</a>)</li>
<li>See full diff in <a href="https://github.com/adobe/node-fetch-retry/compare/v2.0.0...v2.1.0">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/3384
Reviewed By: passy
Differential Revision: D33892201
Pulled By: cekkaewnumchai
fbshipit-source-id: e318850d9bcad6908a92e41080fb64d8efafb183
Summary:
Bumps [typescript-eslint/eslint-plugin](https://github.com/typescript-eslint/typescript-eslint/tree/HEAD/packages/eslint-plugin) from 5.10.0 to 5.10.1.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/typescript-eslint/typescript-eslint/releases"><code>@typescript-eslint/eslint-plugin</code>'s releases</a>.</em></p>
<blockquote>
<h2>v5.10.1</h2>
<h2><a href="https://github.com/typescript-eslint/typescript-eslint/compare/v5.10.0...v5.10.1">5.10.1</a> (2022-01-24)</h2>
<p><strong>Note:</strong> Version bump only for package <code>@typescript-eslint/typescript-eslint</code></p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/CHANGELOG.md"><code>@typescript-eslint/eslint-plugin</code>'s changelog</a>.</em></p>
<blockquote>
<h2><a href="https://github.com/typescript-eslint/typescript-eslint/compare/v5.10.0...v5.10.1">5.10.1</a> (2022-01-24)</h2>
<p><strong>Note:</strong> Version bump only for package <code>@typescript-eslint/eslint-plugin</code></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="3e1ebcad55"><code>3e1ebca</code></a> chore: publish v5.10.1</li>
<li>See full diff in <a href="https://github.com/typescript-eslint/typescript-eslint/commits/v5.10.1/packages/eslint-plugin">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/3382
Reviewed By: nikoant
Differential Revision: D33892140
Pulled By: cekkaewnumchai
fbshipit-source-id: 5185d0dbb9ad2b3db44b3cc8e32fa07e8192fa6a
Summary: Idb and adb sholuld not really be accessed out side of Adnroid and iOS device managers
Reviewed By: lawrencelomax
Differential Revision: D33915162
fbshipit-source-id: 0d1bb028b9a53254cf5b0ce6289ae76339c5a254
Summary: Remove hidden async initialization of adb and idb. Make it explicit. Remove nullable fields in Android and iOS device managers.
Reviewed By: lawrencelomax
Differential Revision: D33915177
fbshipit-source-id: 882f79310410e0dfde6169abf343ab808644e4a2
Summary: Extract WWW certificate provider from the iOS certificate provider. Hide its implementation from OSS since it is not relevant for OSS folks.
Reviewed By: mweststrate
Differential Revision: D33895378
fbshipit-source-id: 376afda3b5fa3857c0eb280b92555314eb1a0d1f
Summary:
Currently, certificateSetup is called in two places:
- processCertificateSigningRequest
- loadSecureServerConfig
`loadSecureServerConfig` is a mandatory step of Flipper server initialization ([ServerController.init](https://www.internalfb.com/code/flipper/[24785758018a2ffbd4751ad2b9093b5ef97c611d]/src/fbsource/xplat/sonar/desktop/flipper-server-core/src/comms/ServerController.tsx?lines=118)). Flipper cannot start without executing it.
As a result, calling `certificateSetup` in `processCertificateSigningRequest` always results in the early return.
This diff removes executing `certificateSetup` from `processCertificateSigningRequest`. Since it's called only during server setup (so only once), it no longer makes sense to use `didCertificateSetup`.
Next steps:
- Extract Android and iOS certificate utils. Remove the dependency on accessing adb/idb dynamically. See D33711652 (da618fd3f3).
Reviewed By: jknoxville
Differential Revision: D33817119
fbshipit-source-id: 675d1e2fe468782da458832c2e88259c92951fdb
Summary:
`idb` has supported video recording on devices for quite some time now. We even have the implementation in `iOSDevice`, but it's currently unused.
As a result, we just need to remove the check within `iOSDevice` that the target is an "emulator" and it will use the `idb` implementation. Removing this check means that the button is now selectable within the UI.
Reviewed By: passy
Differential Revision: D33913383
fbshipit-source-id: b3d6b4c480c79b54f0d2c206c68092ab62bf71ed
Summary: This should in theory never happen since the state of the recording is also managed within the UI. However, it's better to ensure that if `startRecording` is called twice, without calling `stopRecording` first it will error rather than leak a recording (the first process will still run but the object representing it is oprhaned)
Reviewed By: passy
Differential Revision: D33913298
fbshipit-source-id: f8fa6b0e4fdbdf4282633fa29a736d3e7dedf3bb
Summary:
The state of the destination and the process are coupled together. As a result it makes sense to move these to an object type.
This prevents destination and process being independently settable. No change in behaviour, just a removal of invariants that need to be checked
Reviewed By: passy
Differential Revision: D33913213
fbshipit-source-id: ed18650cac4f72d40e82d20254674f7fa12cbb48
Summary: This is public but never read, no need for it to exist
Reviewed By: passy
Differential Revision: D33893097
fbshipit-source-id: aa423464f9cc0c35768a549fd5cb481784d8bcd6
Summary:
There's no need for us to have a property that can be undefined, since we can use the magic of *passing arguments* to achieve the same end result.
The unit test a bit more precarious, but it's left here for posterity or until we decide to kill it otherwise.
Reviewed By: passy
Differential Revision: D33892407
fbshipit-source-id: 3b499511189862e2265d8d6d29f849a7b813050e
Summary:
Bulding on the work from prior diffs we can use the created bridge directly. No need to have if statements calling out to sub-functions, just use the base type itself which will use the appropriate implementation.
There's no behavioural change here. Either idb was queried for sims/devices or simctl was queried for just sims, they were always mutually exclusive.
Reviewed By: passy
Differential Revision: D33842604
fbshipit-source-id: 0bf63ffc34368c70df31c105ea0ba5df941e72cc
Summary:
We perform this *repeatedly* (every 2s!!!). Which is clearly excessive.
Let's perform this check once to avoid noise and a waste of system resources
Reviewed By: passy
Differential Revision: D33844194
fbshipit-source-id: 226dc9d67bb83b167afa8e28ade8e1911470ef8a
Summary:
This runs in a very hot loop (which I will change shortly)
However, there's also some simplification that we can do here:
- Only look for `Simulator.app` processes instead of all the processes. This limits the amount of string comparison to do. If there's a `Simulator.app` running, then we know a sim is running for that Xcode.
- Use piping to extract the launch path of the process, instead of then regex'ing this out.
- Use a simpler substring match to determine if paths have a different start.
Reviewed By: passy
Differential Revision: D33891296
fbshipit-source-id: e37d5f260fc6c6113be9c5268b7c8cffb4057b9a
Summary:
Again this is just a code move for now.
However, we now have a common method between simctl and idb cases. This means that the next diff can call an `IOSBridge` with polymorpism taking over. This is still delegated out, but there's an argument to be made to move `iosUtil` functionality back so that this all lives in the same place.
Reviewed By: passy
Differential Revision: D33843093
fbshipit-source-id: 5cd884140817df851cccf63e5780582b16d4231c
Summary:
Extracts `getSimulator` interrnals to `SimctlBridge`. This allows this functionality to be used independently of things like the the flipper server.
For now this just moves the functionality, but future diffs will build on top of this.
Reviewed By: passy
Differential Revision: D33842986
fbshipit-source-id: bae26a9bd5c21c9813f8a2b10c3b3e3efc1c5929
Summary:
This is related to `simctl` functionality, so can be extracted there.
This will aid in future changes whereby we can hide `getDeviceSetPath` in the IOSBridge module
Reviewed By: passy
Differential Revision: D33842987
fbshipit-source-id: de292ce5afba3e7d79d8ba27c2b8852909d7e6f3
