User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

I opened http://www.motherfuckingwebsite.com/ linked from https://www.reddit.com/r/firefox/comments/g088xp/questions_to_mozilla_from_a_ux_designer_and_is/fn8s97f/ and noticed connection is not secure so I will like to append 's' to `http' protocol.

Actual results:

There is no protocol when editing in address bar.

Expected results:

I can understand protocol is hidden in normal view, but it should be available for editing.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

http is stripped from the value, in the future we may decide to strip https instead. As such it's expected to not be present because editing the url is still un-ambiguous. You can of course add "https://" in front of it.

Masatoshi-san, why did you mark this as a regression of bug 1617029? I just tested with Firefox 74 and I don't see a difference in behavior.

And the main reason to not add back "http" is to avoid the text jumping on focus in the most common cases.

This is actually old https://bugzilla.mozilla.org/show_bug.cgi?id=665580 but for some reason browser.urlbar.trimURLs was reset on my side. Should be closed as invalid or whatever.

I'm not able to append 's' to the protocol to switch to secure site, because there is no protocol in address bar

That's the goal of bug 1067293.

Sorry, but last word: I think it's stupid design to force users to type https:// when they want to switch to secure website and switching to unsecure requires to only remove one character.

users are a lot more annoyed by the jumping text (and not just annoyed, some users suffer migraine because of moving things) than having to type "https". A decision had to be made.

:) There is no jumping text when browser.urlbar.trimURLs is false, so it's design failure.

If Mozilla just disabled browser.urlbar.trimURLs, users might get confused and think http is https. IMHO it would require to flip security.insecure_connection_text.enabled as well.
It could be evaluated as an intermediate step before enabling a default-to-https pref (bug 1628831/bug 1067293) in the long term.