Handle initial network connectivity

[whitecrownclown]

@sindresorhus ,

Hello!

This PR should fix the initial app launch issue with network connectivity and also allow for Caprine to be launched on system start/login without the need of a manual refresh. (Fixes #421)

Any feedback is welcome. Thanks!

[CvX]

I don’t think this is a correct way to approach connectivity problems.

1. Reloading the page is one of the triggers of the bug described in Vibrancy issue, gray sidebar #712.
2. User could be interacting with the app when the reload happens which isn’t great user experience.
3. If someone’s connection keeps dropping the app would reload constantly. Not ideal either.

We have to find a different way to force Messenger to re-establish its connections.

[whitecrownclown]

@CvX I know it's not a great way to do it, but this PR only handles initial connectivity, before the user has a chance to interact with the app (for example, launching the app at login, when most of the time there's no internet connection and the app remains unresponsive/blank page). I'm not sure about item number 1, but 2 and 3 would definitely not apply here.

[CvX]

Ah, my bad! 😶 In this case, you’re right, disregard 2 and 3.
And to handle 1 it might be better to do what we do when switching between standard messenger and work chat?

app.relaunch();
app.quit();

[whitecrownclown]

@CvX Yes, i could make that change, the reason why i didn't go for that at first is that to the user it will look more like a bug and it also takes a bit longer to load. Is there no way we could reload the mainWindow and find a fix for #712 ?

[CvX]

That would be ideal, but I'm afraid it might take quite a while to fix #712, since it's possibly a bug in Chromium.

I'd suggest doing a full app relaunch for now and adding a TODO comment to remind us to change it to a simple reload as soon as #712 is fixed.

[whitecrownclown]

@CvX Alright, i've done exactly that. Thanks!

[CvX]

Alright, I've tried it out! 👨‍🔬
Other than the suggested minor changes, it would also be great if we used something like p-wait-for (with an interval of ~1000ms) so it isn't so hard on the CPU. 🙂 What do you think?

[whitecrownclown]

@CvX I've updated the PR and also used p-wait-for instead of the while statement.

[sindresorhus]

This results in a weird experience if you're actually offline. Then the app is just on the Dock without anything happening or showing. I think we need a timeout after 20 (?) seconds where it shows an error message to the user that they're offline, and with a "try again" button.

[CvX]

I've tried the this PR on Windows, and a couple of times the relaunched app's window was blank. I didn't find out the root cause, but instead I decided to try a simpler solution: wait for the connection before creating the window. Let me know what you think @whitecrownclown, @sindresorhus.

[whitecrownclown]

@CvX I think it's both simpler and better. No need to relaunch app/ reload window. I did notice that after this change triggering window 'activate' will throw an error so i added in a small check.

[sindresorhus]

This is not really a generic utility (And the method name is outdated). I would move this and https://github.com/sindresorhus/caprine/pull/775/files#diff-21e9ddd93162651bd36f6e5bbfca8460R282 into a new file to contain the logic.

So in index.js, it would just be:

(async () => {
await ensureOnline();

await app.whenReady();

...

[CvX]

btw. these awaits don't have to be sequential, so we can change that to, e.g.:

await Promise.all([ensureOnline(), app.whenReady()]);

[sindresorhus]

@CvX There's not really any benefit in using Promise.all here as app.whenReady() doesn't do any work. It's just a shortcut for checking for the status of the app load. So the result of using Promise.all is exactly the same as before. But it's fine, we can keep it.

[sindresorhus]

@CvX Good solution!

[CvX]

I've renamed showRetryDialog to showWaitDialog and did some minor cleanup.

[CvX]

@sindresorhus Prettier disagrees with you 😉

[sindresorhus]

Good work everyone :)