Detecting a network connection event

[Mythical 5th]

I'd like to detect when a user's computer connects to the internet. I can't find anything useful in the extensions API, so I think I will have to use navigator.connection within an Offscreen document.

I thought I'd see if anyone here knows of a better way. I note that the list of reasons for offscreen pages does not include navigator.connection but does include 2 other properties of that interface, so that doesn't make me feel confident.

https://developer.chrome.com/docs/extensions/reference/api/offscreen#type-Reason

[Patrick Kettner]

It depends on what you are actually trying to check. The thing you may run into is that just because you have a connection does not mean that it is useful. You can be plugged into a router that has no network access, or a WiFi network that only has intranet access.

When the connection is false, you don’t have internet access. But when it isn’t false, it doesn’t mean you have internet access, only that you don’t not have access. 

A more “robust” check would be to do an OPTIONS or HEAD request to the server you care about with a fetch. 

Patrick 

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/350a14b5-de4d-4da7-8299-46e735c98756n%40chromium.org.

[Mythical 5th]

Thanks. I was hoping not to have to use chrome.alarms and keep waking up the service worker, but it might be the only way.

[Patrick Kettner]

The only way to do what? Why do you need to know the network connection?

[Mythical 5th]

I was trying to resume a download automatically when the connection came back, but I'd like to be more graceful than waking up every few minutes and trying to force it.

[Patrick Kettner]

Gotcha. That actually sounds tailor made for the background fetch API for standard service workers. Have you considered using that?

[Mythical 5th]

That could work, but it would mean not using the downloads API, so not having the download progress shown in the usual place.

Is there a reason that the downloads API does not automatically resume when a connection returns, given that the functionality exists?

[Patrick Kettner]

Can't speak with authority on it, but I would assume it is because the downloads API is about iterating with Chrome's downloads, and Chrome's downloads do not have native "automatic retry" as a feature.

[Mythical 5th]

Sure, but wherever the lack of automatic retry originates, it's odd that it exists. The implied assumption is that when someone downloads a file and it fails for an easily-recoverable reason, they don't want to be told about it and they don't want it to be fixed, they just want to be given a button to click if they happen to notice the error before the server times out!

[Patrick Kettner]

Sure, not saying it’s a bad idea. But stepping back that API is an extension interface to chromes download system. So if chrome, supported automatic retry, the extension API likely would too. It also isn't likely to add arbitrary features that are unique to extension specific downloads.  

If you open a feature request, I'd be happy to advocate for it!

[al]

In a similar case (I can't comment on Mythical 5th's case), I'm needing to fetch dynamic resources (can't be packagaged within) after an update, and after reading Patrick's suggestion, I've landed on Background Sync. But it looks like I need an Offscreen Doc, since the operation occurs solely within the SW and you can't register a SyncManager from within.

Meaning, on Updated, create an Offscreen document, just to register the Sync Manager, so that once/when the client is online (if not already), the SW can perform the requests.

For my case, it all has to be done in the background. It could also apply to any SW fetch connectivity fail (not just on updates).

Am I understanding correctly that that's the most optimal way?

It just seems to add quite a bit of cruft, and I'm weary of the performance impact.

(I'm also weary of the fact that BG Sync is Chromium only)

The alternative is the occasional HEAD request, but now you have to do that on every SW wake, which (for me) is dependant on user activity.

[al]

Looks like I was mistaken - Background Sync behaves similarly to navigator onLine / connection, where not offline applies, as opposed to true internet access. 

Meaning regardless of the method, you need a fetch request. 

On that note, what would the most optimal request be? I've settled on a HEAD to "www.google.com", as a quickest (certainty of geo-close servers) and most reliable (uptime) option.

I guess it's also likely that the DNS will have been cached. (maybe?)

Would this, and assumptions from the previous comment be correct?

[Mythical 5th]

I opened a feature request

https://issues.chromium.org/issues/405044138

Technically it's a bug report, because that's the only option.