Makes sense. Toast is too small to be noticed. I appreciate if you can suggest a better way to enhance error state ux?

Umm, we could improve the error UX. But the problem we are facing is that browsers don't let the full details of the network error to be given to the scripts. As far as the script is concerned, we are only given a "Network Error" message and it is pretty generic and is thrown for every network related issue, not only the one you mentioned as an example.

Since we can't exactly know what went wrong, we really can't suggest anything on how to fix it.

This isn't a general solution for any CORS policy - but it would allow us to figure out perhaps if we need to show a full-page dialog prompting them to install the browser extension or enable the proxy.

We could perhaps set up an API route that works in every way except by having an Access-Control-Allow-Origin policy to a random domain. That way we could test by first requesting a 204 to some domain (to establish that the device is connected to the internet) and then make a request to our CORS route - if it succeeds, proxy or extension is enabled, if it fails, the error must be due to CORS hence we can show the full-page dialog.

@AndrewBastin this is new to me. The script just gets "NetworkError" without a message? Hmm let's focus on this. How could this be changed? Of course this is not an issue of hoppscotch any more, but on the other hand we could make life easier for thousand developers. Who could help here?

I don't think we have any other ways to get it from a browser request stand point.

The solution provided by @NBTX sounds great. But I don't really encourage it because of security concerns and the user not knowing that request is being ran on the background through a proxy.

@satyam-52 I don't know how this fits into the conversation here exactly.

Hoppscotch already has a built in proxy that circumvents this issue. You can enable it in the Settings page.

@AndrewBastin Just re-read the problem, I just misinterpreted. Will delete my comment :)

@AndrewBastin

because of security concerns and the user not knowing that request is being ran on the background through a proxy.

Hmm? How is this any different from running similar network requests (google analytics, feature tracking)?
If the request is being run through a proxy, it is because the user (or someone on their behalf) explicitly enabled it.

I think adding a route like /connectivity-check/?cors=true to proxyscotch should allow checking both for network connectivity and if CORS is blocked.
As for mixed content, checking requestUrl.protocol == window.location.protocol should cover most cases.

Maybe related: #2248

Can I work on this?

Hi @imskr, feel free to pick up this feature. Do let us know if you need any help.

Hi @liyasthomas, is this still open?.. can i take it?
also how are we planning to show the message on the client side?
do we show some popup notifications (like Toast, which i read above)?

can I work on this?

Assign me please , i want to work on this