Bugzilla

(In reply to Daniel Veditz [:dveditz] from comment #1)
> "enters", or "types"? I am 100% with you if the user is _typing_ "http://", but I'm less sure if they paste it. Maybe they mean it, but more likely they just copied it from some other location that's wrong. For example, if you type a domain-looking thing like some.words.com, Slack will turn it into an http:// link. I've seen it on other apps and sites, too. Those are almost always not what anyone explicitly wanted, and wrong 90% of the time according to Firefox page load stats.
> 
> I don't know if that's an easy distinction to make or not in the URLbar code.

As mentioned in my original comment, it would be nice to have a more "advanced" way of determining if the user actually typed the "http://", or just pasted it. The current `browser.urlbar.trimHttps` (enabled in Nightly) does make some distinctions based on user input, mainly to determine whether to display the scheme or not while editing. But I don't think that maps well to what we want to do here. If we do want a more advanced detection of if the user has edited the scheme or not, we could ask the address bar team for help.

But generally, if such a detection logic makes this way too complex, I also don't think it would be terrible to not have any special logic, and just look at the `wasSchemeless` we already have. In the end, even when just pasting a http://example.com and hitting enter, that can still be interpreted as the user explicitly wanting to load example.com through HTTP.

> Could we add some indication that we've manually upgraded the url? [..] We could maybe decorate the lock, but the lock is being merged into the shield sometime soonish. Maybe this is a terrible suggestion :-) 

This sounds like a good idea to me. We could display some sort of small arrow pointing up in the corner of the lock icon (symbolizing an upgrade) every time, we currently would display `(Upgraded to HTTPS)` under the panel opening when the lock icon is clicked. That would also lead users to HTTPS-Only/First opt-out UI in the lock icon panel.

> I know other permissions do that, so that if you forgot you granted a particular permission to a site there's a clue where to click to change it. But that's awkward for this. The icons that currently show up are all added to a single button that opens the site preference pane, so we can't put it there.

Maybe I am also not completely understanding what you propose. Are you saying we should add a UI indicator a) when we successfully performed an upgrade, b) when we have an exception set for the site, or c) in both cases?

In any case, this idea seems to be separate from this particular bug, so let's continue discussion in Bug 1676227.

> I agree we'd have to add a temporary exception for that case. "Hidden" exception? What if the user changes their minds and wants to clear it? I'm unfamiliar with what you did for bug 1884921 so I'll look over there.

Yes, this still is kind of an open question. If we added session exceptions with the type added in Bug 1886184, there would be no way for the user to override them, other than restarting the browser. If we were to expose this, we would also need to update the permission UI. This is because we only want to add an exception for HTTPS-First, not HTTPS-Only. I had some explorations on this in [D205714](https://phabricator.services.mozilla.com/D205714), see the attached screenshot for what that would look like.

But at the same time, having the exceptions "only" last a session is also not ideal. For example, if the user bookmarks a site exempted through this mechanism, and then loads that bookmark after a browser restart, it will get upgraded again. We could consider just not HTTPS-First upgrading bookmark loads (with the same temporary exception), as at the point a bookmark is set, an upgrade should either have already happened, or the site does not work with HTTPS. But that would also mean that bookmarks set before HTTPS-First was enabled won't get upgraded, and also that sites which retroactively gain HTTPS support won't be upgraded. So I am not sure if I have a good solution here.

(In reply to Simon Friedberger (:simonf) from comment #3)
> I like this idea but should we consider making the other option for preventing the upgrade more discoverable?
> Making people go to the settings to add an exception is too much work. 

As mentioned above, adding an indicator to the lock icon could help in that regard.

> And it seems like the identity panel isn't even always offering the option to downgrade.

It only is displayed when HTTPS-First or -Only interacted in some way with the load, so either if it upgraded the load, or an exception is present.

> If we had a simple button "Try insecure HTTP instead" in security panel that might be enough.

The problem with displaying such a button universally is that you would generally not be able to downgrade for example HSTS with it. So I am not sure that a button, which sometimes just does nothing, is better than what we currently have (just not display any HTTPS-First UI in case it wouldn't do anything). But what we could consider is changing the current dropdown to something more intuitive, like a "downgrade" button.

(In reply to Daniel Veditz [:dveditz] from comment #1)
> "enters", or "types"? I am 100% with you if the user is _typing_ "http://", but I'm less sure if they paste it. Maybe they mean it, but more likely they just copied it from some other location that's wrong. For example, if you type a domain-looking thing like some.words.com, Slack will turn it into an http:// link. I've seen it on other apps and sites, too. Those are almost always not what anyone explicitly wanted, and wrong 90% of the time according to Firefox page load stats.
> 
> I don't know if that's an easy distinction to make or not in the URLbar code.

As mentioned in my original comment, it would be nice to have a more "advanced" way of determining if the user actually typed the "http://", or just pasted it. The current `browser.urlbar.trimHttps` (enabled in Nightly) does make some distinctions based on user input, mainly to determine whether to display the scheme or not while editing. But I don't think that maps well to what we want to do here. If we do want a more advanced detection of if the user has edited the scheme or not, we could ask the address bar team for help.

But generally, if such a detection logic makes this way too complex, I also don't think it would be terrible to not have any special logic, and just look at the `wasSchemeless` we already have. In the end, even when just pasting a http://example.com and hitting enter, that can still be interpreted as the user explicitly wanting to load example.com through HTTP.

> Could we add some indication that we've manually upgraded the url? [..] We could maybe decorate the lock, but the lock is being merged into the shield sometime soonish. Maybe this is a terrible suggestion :-) 

This sounds like a good idea to me. We could display some sort of small arrow pointing up in the corner of the lock icon (symbolizing an upgrade) every time, we currently would display `(Upgraded to HTTPS)` under the panel opening when the lock icon is clicked. That would also lead users to HTTPS-Only/First opt-out UI in the lock icon panel.

> I know other permissions do that, so that if you forgot you granted a particular permission to a site there's a clue where to click to change it. But that's awkward for this. The icons that currently show up are all added to a single button that opens the site preference pane, so we can't put it there.

Maybe I am also not completely understanding what you propose. Are you saying we should add a UI indicator a) when we successfully performed an upgrade, b) when we have an exception set for the site, or c) in both cases?

In any case, this idea seems to be separate from this particular bug, so let's continue discussion in Bug 1676227.

> I agree we'd have to add a temporary exception for that case. "Hidden" exception? What if the user changes their minds and wants to clear it? I'm unfamiliar with what you did for bug 1884921 so I'll look over there.

Yes, this still is kind of an open question. If we added session exceptions with the type added in Bug 1886184, there would be no way for the user to override them, other than restarting the browser. If we were to expose this, we would also need to update the permission UI. This is because we only want to add an exception for HTTPS-First, not HTTPS-Only. I had some explorations on this in [D205714](https://phabricator.services.mozilla.com/D205714), see the attached screenshot for what that would look like.

But at the same time, having the exceptions "only" last a session is also not ideal. For example, if the user bookmarks a site exempted through this mechanism, and then loads that bookmark after a browser restart, it will get upgraded again. We could consider just not HTTPS-First upgrading bookmark loads (with the same temporary exception), as at the point a bookmark is set, an upgrade should either have already happened, or the site does not work with HTTPS. But that would also mean that bookmarks set before HTTPS-First was enabled won't get upgraded, and also that sites which retroactively gain HTTPS support won't be upgraded. So I am not sure if I have a good solution here.

(In reply to Simon Friedberger (:simonf) from comment #3)
> I like this idea but should we consider making the other option for preventing the upgrade more discoverable?
> Making people go to the settings to add an exception is too much work. 

As mentioned above, adding an indicator to the lock icon could help in that regard.

> And it seems like the identity panel isn't even always offering the option to downgrade.

It only is displayed when HTTPS-First or -Only interacted in some way with the load, so either if it upgraded the load, or an exception is present.

> If we had a simple button "Try insecure HTTP instead" in security panel that might be enough.

The problem with displaying such a button universally is that you would generally not be able to downgrade for example HSTS with it. So I am not sure that a button, which sometimes just does nothing, is better than what we currently have (just not display any HTTPS-First UI in case it wouldn't do anything). But what we could consider is changing the current dropdown to something more intuitive, like a "downgrade" button that is only displayed when the current UI would be displayed.