Change:
setRequestHeaders(xhr, options); xhr.responseType = 'arraybuffer'; <del> xhr.onerror = e => reject(new Error(xhr.statusText && ('XHR failed: ' + xhr.statusText) || 'XHR failed')); </del> <ins> xhr.onerror = e => reject( navigator.onLine ? new Error(xhr.statusText && ('XHR failed: ' + xhr.statusText) || 'XHR failed') : new OfflineError() ); </ins> xhr.onload = (e) => { resolve({ res: {

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.74.3 OS Version: macos ventura Steps to Reproduce: If I knew, I'd know how to fix it. When searching for extensions, VS Code claims that I am offline when I am absolutely not offline. Chrome has the same problem, where says so I suspect your code's using that flag too and that flag is completely useless. Don't use it =)
Is there another reliable alternative?
Just fetch the marketplace domain URL instead of trying to see if there's a network first: if it works, it works. If it doesn't, you handle that in the fetch clause and tell the user that it looks like they're having (this time real) network connectivity issues. There hasn't actually been a reason to look at since the addition of XMLHttpRequest way back when, and more recently, the Fetch API. Too many things (both in and out of the control of the user agent) can interfere with any of the properties found on .
not that I am aware of. the goal with using was to provide a better notification to users (similar to offline page in browsers) when we are confident that connectivity is offline compared to other network errors we receive from the request API. Isn't meant to give a pretty confident response about status. Atleast on macOS, chromium implements this by registering notification via api if is reachable by any network connection on the device. Refs Is there anything in your network setting that would make the above detection not work ?

I know Slack does something "clever" here, if it detects it's running in a browser that claims is it reports so maybe worth asking the Slack folks what they do? Also, while is meant to give a confident response, any number of hardware, firewall, etc. issues can invalidate it without affecting network connectivity to real IPs rather than 0.0.0.0 I'd still recommend "just try to get the URL you need" and if that doesn't work, use that as signal that we need to check what says, rather than the other way around. That way you first do the thing that, if there is network connectivity, will just work. If it doesn't, then you can check "why it might have failed" as part of the error handling (rather than the more naive "retry X times before considering it a connectivity issue" that someone might be tempted to implement in a personal project) and if that says then there's now good enough evidence to tell the user that they're offline.
seems reasonable that we move the offline status check once the request has failed to address these scenarios.

<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --In response to , I think this error should only be raised when a request actually fails. I have a network setup where my host operating system reports it doesn't have network connectivity, but it can actually reach the internet just fine through a configured proxy. I believe moving the online check to the would result in a more accurate error flow: Obligatory xkcd for my unique situation:
As mentioned by I expect shall provide right info whether VS Code can connect to internet or not. Is it possible to get this info from the error instead of ?