Summary: This is a duplicate, is not needed, causes confusion.
Reviewed By: aigoncharov
Differential Revision: D51307091
fbshipit-source-id: 4d55d727ea5f20100ecd15ad6e23aa0c01722524
Summary: Make both prod and dev HTML entry points identical.
Reviewed By: aigoncharov
Differential Revision: D51307116
fbshipit-source-id: 5aea8e455d623aba260e3e37a2c549ebc67dd3b0
Summary: Not entirely sure what the use of this socket is, but it can definitely be defined inside flipper-ui-browser instead.
Reviewed By: aigoncharov
Differential Revision: D51307090
fbshipit-source-id: 36eb336536e8672fb0b2bcf12dad31c7fbc00a39
Summary: These logs only available on debug but we already have these logs coming from the actual used socket, so remove.
Reviewed By: aigoncharov
Differential Revision: D51307089
fbshipit-source-id: 32e3eada42fa54b429df0bfcdd936d24cebaf0cb
Summary: These two texts were different, they should be the same for consistency.
Reviewed By: aigoncharov
Differential Revision: D51307086
fbshipit-source-id: a71fb7e6cf072df73e7f9fb386245f266984900b
Summary: This CSS was unused, so remove.
Reviewed By: aigoncharov
Differential Revision: D51307093
fbshipit-source-id: a978d76fca7cfb07c96180c4ece0b1bdf1087894
Summary: Instead of having duplicate configs defined on our HTML. Move the config definition to the server.
Reviewed By: aigoncharov
Differential Revision: D51307092
fbshipit-source-id: 68f4afc918cf191b3a15b3981429c5a05d5df8df
Summary: After the move, let's rename the constants to make them match our code standards.
Reviewed By: aigoncharov
Differential Revision: D51307087
fbshipit-source-id: 4e44e956fd88abd3e8359fe94fa4e31d17f61a55
Summary: Recently we have added a few constants to be used by our main entry point. This change moves them to a central place: flipperConfig.
Reviewed By: aigoncharov
Differential Revision: D51307088
fbshipit-source-id: 09f0ef0e69e2067ce5c8501367629eeec7523858
Summary:
Auth token used be injected in the manifest file. Instead, have the server injected into the main HTML page.
The main driver to this change are:
- Simplify
- There are instances in which for some reason reading/writing the token from the manifest fails. This will address that problem.
Reviewed By: lblasa
Differential Revision: D51160521
fbshipit-source-id: 4626fd8f56bc8b61182a53a5d9cf5acad1e723bc
Summary:
The previous offline page suggested launching Flipper from terminal by running a command.
Although this works, guidance can be simplified by just instructing users to launch Flipper from within the Applications folder.
Reviewed By: aigoncharov
Differential Revision: D50833741
fbshipit-source-id: 5a41090a66ee62c30cfc35edd69de51ed9cbbab9
Summary: If we fail to load the main js bundle, retry after 3 seconds.
Reviewed By: aigoncharov
Differential Revision: D50732857
fbshipit-source-id: b19ea165776f8105d724e586b1bed20bf1f5178c
Summary: Previously I had created a RN build, locally, with a few minor differences. That had to be reverted. Instead of reverting and re-applying changes, I'm introducing a flag that can be used in the interim to produce the RN-only builds.
Reviewed By: LukeDefeo
Differential Revision: D50555055
fbshipit-source-id: edface9a1587fb51e54eebe73724032baf985c83
Summary:
Currently we download a bunch of FB icons and we normally use the smallest one available.
In this diff I change the download logic so we try to download from the largest to the smallest icon and use the first one available. One the client we no longer provide the icon of the same size that is requested, instead we provide the only one we have which will typically be larger than needed. This is a good thing because
1. flipper is a local application and we do not need to worry about icons take up broadband and downloading
2. People have high density displayed
I also stopped using density(rest of related code removed in the next diff) for icons as it the icons themselves did not support it.
Reviewed By: lblasa
Differential Revision: D50495194
fbshipit-source-id: f569c2f3b8ee424a67c6d21136e7e113868b8f6a
Summary: Changelog: When requesting Keychain Access, you will now see "flipper-runtime" instead of a generic "node" process.
Reviewed By: lblasa
Differential Revision: D50261830
fbshipit-source-id: ef6fd7d5099c4ff7370f0401a5de3fde1659f1f3
Summary:
As discussed with lblasa. This solves a few issues:
- Confusing names in `ps` and Activity Monitor related to Flipper.
- Permission requests for the Keychain from "node" lead users to deny it.
- Seeing "node" as allowed apps for an entry in Keychain is confusing.
Reviewed By: lblasa
Differential Revision: D50232337
fbshipit-source-id: 3bc92aae0ca31d1a80582fb8a794bbc64fc2f2e5
Summary:
This will automatically invoke the "Start" button if Flipper detect it is offline, to automate that step. It will do so only once
(safe for the reload logic that also triggers on server errors, not sure if that was intentionally?)
Reviewed By: lblasa
Differential Revision: D50074673
fbshipit-source-id: 2c11e80429a2c4ed0e43e62cb2f6057fad5eb410
Summary: Change the button title when clicked.
Reviewed By: mweststrate
Differential Revision: D49954493
fbshipit-source-id: 3d689effc0cc5587ab8a07901b66139577b21837
Summary:
Simplify how messages (state updates) are shown in Flipper UI.
This main change was introduced as a way to show the 'Start' server button whenever we were in a disconnected state. This is not as simple as the server may be restarting or the client may be even have reset the WS connection. Hence you the experience where this UI is shown and immediately dismissed.
This UI is only ever shown if at one point the server was alive, period. So, in this case, either the server becomes available again OR the user quits the PWA/tab/browser and launches again.
IMHO, this is a better experience that totally assuming the server is dead.
In a next iteration, we can be more clever and have a timeout such that if after a set period of time the server doesn't become online, then we show a button to start (or force kill) the server.
Reviewed By: aigoncharov
Differential Revision: D49915698
fbshipit-source-id: 03fcc150ed1f1303d1d727c82a71eb32616208e8
Summary: Also remove the suppress error usage as is it was never used.
Reviewed By: aigoncharov
Differential Revision: D49910876
fbshipit-source-id: 7267eaddadb73ab2b6e2aab0045157271ceed427
Summary:
The icon was not shown in the past as it was indefinitely bouncing on the dock.
This is fixed now by asynchronously initiating the Node server process and then waiting until it becomes ready.
Reviewed By: passy
Differential Revision: D49907976
fbshipit-source-id: cdeaa578be42d9f5308e2e0df50872858b8248c3
Summary: Not in use in this diff, but it will be for next diffs.
Reviewed By: antonk52
Differential Revision: D49823258
fbshipit-source-id: 364414d7c37a14c6a166b33b9229e6f874f7f146
Summary: For the last stable Electron version, do not delegate to Launcher.
Reviewed By: antonk52
Differential Revision: D49821835
fbshipit-source-id: 0a80627cd1da312447b7d98d0351aa8faf2bae89
Summary: Let's keep it simple, do not reload. Just show/hide the right content.
Reviewed By: antonk52
Differential Revision: D49377316
fbshipit-source-id: 9b2a47374da3e72f17e2d55c9290960b703fd43e
Summary:
Whenever there was a connectivity error, we would show an error message and setup a retry mechanism as to refresh the page as to make it transparent for engineers to have a working workspace again.
The problem is that there are two different channels:
- HTTP server
- WS server
If the HTTP server is healthy but there is a WS error, it is not entirely correct to try to reload the page. If the error conditions for the WS remain, then we end up in a loop.
Reviewed By: passy, antonk52
Differential Revision: D49373335
fbshipit-source-id: 4e0a08fe2384860db0bf92a22edc87402d41651c
Summary:
The existing loading page was not behaving the way it was intended. The previous implementation triggered a page reload which made the whole retry mechanism useless.
Instead, a new endpoint was defined to expose whether the server is ready or not. Use this instead as a way of knowing whether we are good to reload the page.
Reviewed By: passy
Differential Revision: D49314749
fbshipit-source-id: eb67765d7deab8610fa5d31e710070da43a18c1c
Summary: A few improvements to the installation wizard.
Reviewed By: antonk52
Differential Revision: D49145069
fbshipit-source-id: 1aadd85e1d187bd61983a0b4201b530cbdbf509a
Summary: Push the timeout to one second. Users are not going to mind if we try to load after a second but they can mind if they see their tab attempt to reload several times a second.
Reviewed By: ivanmisuno
Differential Revision: D49054898
fbshipit-source-id: 132168a1d6d381f76500bcc9c0a00e05ef0c541b
Summary:
Before this change, opening deep-links or importing files would open new windows.
Instead, just use an existing window if there is one.
Documentation: https://developer.chrome.com/docs/web-platform/launch-handler/
Reviewed By: lawrencelomax
Differential Revision: D48865950
fbshipit-source-id: 80c3fb58f1fcc3b8ace00fd9241bf1e374c8345e
Summary:
Flipper Launcher downloads, unpacks, launches Flipper, and closes itself.
This is fine except for the fact that Flipper may be initiating and thus there's a gap of a few seconds until engineers see the main Flipper UI.
This change improves this by launching earlier, even if just showing a loading page until Flipper is actually ready.
Reviewed By: passy, aigoncharov
Differential Revision: D48824479
fbshipit-source-id: aa6147a09f313d80592c9b08d089660ba73773a4
