Reload tabs when the computer resumes

[yuya-oc]

Before submitting, please confirm you've

• read and understood our Contributing Guidelines
• completed Mattermost Contributor Agreement
• executed npm run lint:js for proper code formatting

Please provide the following information:

Summary
Reload tabs when the computer resumes.

If the computer is offline when resuming from sleep, the app doesn't reload any tabs to keep their contents.

Issue link
#461

Test Cases
Tested on macOS 10.12.3

Case 1:

1. Let the computer sleep.
2. Resume from sleep.
3. The app should reload all tabs immediately.

Case 2:

1. Turn off Wi-Fi or unplug LAN cable.
2. Let the computer sleep.
3. Resume from sleep.
4. The app should NOT reload any tabs immediately.
5. Connect the computer to a network.
6. The app should reload all tabs.

Additional Notes
https://circleci.com/gh/yuya-oc/desktop/200#artifacts

[jasonblais]

@yuya-oc tested on Windows 10

After waking computer from sleep, each tab begins to reload

However, it seems the reloading process takes a really long time -- the page doesn't actually appear until I refresh the tab. Reproduced on the pre-release server and one of our test servers. I attached some console errors that might be relevant

[yuya-oc]

Thanks for catching! I missed that because badges was correctly updated.

I'm not sure the reason why this problem happens, but it's fixed by applying Electron's notes for webview on my Mac. Originally I worked on this at another branch though, I added it to this PR.

https://circleci.com/gh/yuya-oc/desktop/207#artifacts

[jasonblais]

I seem to be hitting the same issue - the tabs do start to reload, but it seems to take a long time

Interestingly, the tab loads properly for test sites like example.com

and test.com

[yuya-oc]

Hmm...interesting. But I'm not sure. Perhaps it's too early to reload even when the computer is online in resuming.

And unfortunately I found another problem on my Windows 10 desktop. The reloading fails due to ERR_NETWORK_CHANGED error. Long (more than 5 seconds) delay was necessary to avoid it, so the delay might not comfortable.

Just curious, does mattermost/mattermost#5120 make sense for the original problem of #461?

[jasonblais]

Yeah, mattermost/mattermost#5120 is related -- however the PR was included in Mattermost 3.6, and some people reported missing messages on that server.

However, we just had another PR merged (mattermost/mattermost#5907), which adds a sequence number to WebSocket connections and events -- that sequence is used to determine if any events were missed and run reconnect logic to get that missed data.

So I can check on Monday whether that PR would be sufficient to cover #461

[jasonblais]

@yuya-oc chatted with Joram - although mattermost/mattermost#5907 won't be the perfect solution for resolving missing messages, it might be enough for this purpose. So propose keeping this PR as pending until Mattermost v3.8 is released and asking the original issuer to report back whether missing messages continue

[yuya-oc]

@jasonblais Okay. But the patch for webview seems necessary, so I will apply only it later.

[jasonblais]

Thanks @yuya-oc, sounds good

[jasonblais]

@yuya-oc Since Mattermost Server v3.8, there haven't been issues with missing messages. Hence, propose closing this PR as well as #461

[yuya-oc]

@jasonblais I agree. Thanks for feedback.