A bit more nuance, though: **Specifically on Android**, though, I do see Chrome and Firefox Nightly unconditionally giving expected-results here -- I don't ever get an error page there (even starting with a fresh user profile). It looks to me like that's because both Firefox Nightly on Android and Chrome-on-Android unconditionally upgrade `http` to `https` and hence get expected results here. I'm guessing that's because both Firefox Nightly and Chrome are failing to distinguish between schemeless and HTTP uris on Android, due to lacking the appropriate logic in their URL bar code to tell whether the user typed in `http://` or not and pass that through to the https-first logic. (I suspect that's part of the explanation on Firefox Nightly at least; that's covered in bug 1901120.) That Android behavior is arguably a bug rather than an expected-outcome; if a user goes to the trouble of manually typing out `http://` in their URL (which is more-cumbersome-to-do on Android), it's odd for the browser to disregard that. Bug 1919544 has some justifications for why that upgrading is weird/unwanted. So we probably shouldn't be coming at this from a stance of expecting that behavior. So: I don't think we should really consider this to be a webcompat problem, since (a) the issue seems to really just be a site misconfiguration, (b) all browsers get the same bad-experience from that site misconfiguration on Desktop at this point (at first load), and (c) the issue goes away once you've loaded the https site (or omitted at least once There is one Firefox-for-Android specific issue here, though -- if you just type "nih.gov" (schemeless) and hit enter, *that* should technically get upgraded, but it currently fails to do so. That's due to bug 1901120. So, bottom line: (1) I'd suggest that we consider the network-error on http://nih.gov/ to be expected-results (2) I'd suggest that we morph this bug to be about getting a network error (by loading the http URL first) when the user simply types `nih.gov` (schemeless), which is a version of bug 1901120.
Bug 1868167 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
A bit more nuance, though: **Specifically on Android**, though, I do see Chrome and Firefox Nightly unconditionally giving expected-results here -- I don't ever get an error page there (even starting with a fresh user profile). It looks to me like that's because both Firefox Nightly on Android and Chrome-on-Android unconditionally upgrade `http` to `https` and hence get expected results here. I'm guessing that's because both Firefox Nightly and Chrome are failing to distinguish between schemeless and HTTP uris on Android, due to lacking the appropriate logic in their URL bar code to tell whether the user typed in `http://` or not and pass that through to the https-first logic. (I suspect that's part of the explanation on Firefox Nightly at least; that's covered in bug 1901120.) That Android behavior is arguably a bug rather than an expected-outcome; if a user goes to the trouble of manually typing out `http://` in their URL (which is more-cumbersome-to-do on Android), it's odd for the browser to disregard that. Bug 1919544 has some justifications for why that upgrading is weird/unwanted. So we probably shouldn't be coming at this from a stance of expecting that behavior. So: I don't think we should really consider this to be a webcompat problem, since (a) the issue seems to really just be a site misconfiguration, (b) all browsers get the same bad-experience from that site misconfiguration on Desktop at this point (at first load), and (c) the issue goes away once you've loaded the https site (or omitted at least once There is one Firefox-for-Android specific issue here, though -- if you just type "nih.gov" (schemeless) and hit enter, *that* should technically get upgraded, but it currently fails to do so. That's due to bug 1901120. So, bottom line: (1) I'd suggest that we consider the network-error on explicit loads of http://nih.gov/ to be expected-results (since that happens in Chrome/Firefox-on-desktop too). (2) I'd suggest that we morph this bug to be about getting a network error (by loading the http URL first) when the user simply types `nih.gov` (schemeless), which is a version of bug 1901120.
A bit more nuance, though: **Specifically on Android**, though, I do see Chrome and Firefox Nightly unconditionally giving expected-results here -- I don't ever get an error page there (even starting with a fresh user profile). It looks to me like that's because both Firefox Nightly on Android and Chrome-on-Android unconditionally upgrade `http` to `https` and hence get expected results here. I'm guessing that's because both Firefox Nightly and Chrome are failing to distinguish between schemeless and HTTP uris on Android, due to lacking the appropriate logic in their URL bar code to tell whether the user typed in `http://` or not and pass that through to the https-first logic. (I suspect that's part of the explanation on Firefox Nightly at least; that's covered in bug 1901120.) That Android behavior is arguably a bug rather than an expected-outcome; if a user goes to the trouble of manually typing out `http://` in their URL (which is more-cumbersome-to-do on Android), it's odd for the browser to disregard that. Bug 1919544 has some justifications for why that upgrading is weird/unwanted. So we probably shouldn't be coming at this from a stance of expecting that behavior. So: I don't think we should really consider this to be a webcompat problem, since (a) the issue seems to really just be a site misconfiguration, (b) all browsers get the same bad-experience from that site misconfiguration on Desktop at this point (at first load), and (c) the issue goes away once you've loaded the https site (or omitted at least once There is one Firefox-for-Android specific issue here, though -- if you just type "nih.gov" (schemeless) and hit enter, *that* should technically get upgraded, but it currently fails to do so. That's due to bug 1901120. So, bottom line: (1) I'd suggest that we consider the network-error on explicit loads of http://nih.gov/ to be expected-results (since that happens in Chrome/Firefox-on-desktop too). (2) I'd suggest that we morph this bug to be specifically about what happens when the user simply types `nih.gov` (schemeless) -- that fails right now, only in Firefox-release-on-Android, and that's a version of bug 1901120.