This seems related to bug 1634592, but I thought I'd file it separately since I'm not sure I need the fix suggested there.

web-platform-tests has 260 different domains that are web-platform.test, not-web-platform.test, or subdomains thereof.

The problem I encounter is that I type web-platform plus some search terms, say url, select a match in the dropdown that's indicated with the globe with the keyboard (say http://web-platform.test:8000/url/) and then further manipulate it (say add resources/). Then it changes from a globe to a search.

Ideally we make use of the fact that the domain has been visited before and not require the user to manually prefix a manipulated URL with http:// to prevent it from being turned into a search.

Incidentally this does not happen with the https://web-platform.test:8443/ counterpart so it may be related to hiding http://.

(In reply to Anne (:annevk) from comment #0)

This seems related to bug 1634592

yes, it's likely.

Incidentally this does not happen with the https://web-platform:8443/ counterpart so it may be related to hiding http://.

Ah, I see, we put in the input field the trimmed url when you select the result, when you edit the entry we don't pick the result url, we instead consider the search string, that ends up being a search because the domain is invalid/unknown.

Of course bug 1634592 will solve the *.test case, though we should probably not trim the url if the domain is invalid.

[Tracking Requested - why for this release]:
Recent UX regression that'll hit web devs and other expert users.

Marco, can we get an assignee for this 77 regression? Thanks

yes, I was already planning to take it but forgot to assign.

As I explained in #search the problem here is trimming, if the result points to "http://unknown.probably.invalid/something", and we trim it, we end up with "unknown.probably.invalid/something". Now if the user just confirms the entry we "pick" the result and everything is fine. If instead the user closes the results pane (esc) or edits the value, then because the domain looks invalid, we consider it a search string. But the original result was a url, so we should not change its nature.

I found 2 possible paths to fix this:

1. we stop trimming the value when it's set by a result, so basically moving through the results with the keyboard always sets an untrimmed value. I don't see many downsides to this, the input field may look a bit uglier when selecting entries, but either the user will visit it or they want to edit a url, in both cases doesn't seem that trimming gives much value.
2. when a result is selected and gets trimmed, we pass the value to URIFixup and if its nature changes, we untrim it.

Now of course option 2 is more expensive, on every trimmed value selection we'd have to go through URIFixup, that may not seem much now considered only http is trimmed, but in a future world where most things are https and we trim https, it would be a price we may not want to pay.
I have a patch implementing 1 for now, and I'd like feedback about picking that approach, or alternative ideas.

(In reply to Marco Bonardo [:mak] from comment #5)

I found 2 possible paths to fix this:

1. we stop trimming the value when it's set by a result, so basically moving through the results with the keyboard always sets an untrimmed value. I don't see many downsides to this, the input field may look a bit uglier when selecting entries, but either the user will visit it or they want to edit a url, in both cases doesn't seem that trimming gives much value.

I think that's undesirable UX but would like verdi to weigh in. Right now it doesn't matter much because we don't trim https:// (which is prevalent) but that will change sooner or later (as you've already noted). So I think UX-wise option 2 would be the way to go.

Imo it's not undesirable, considered the user intent is clear, they want to edit a url, and it comes after selecting that from a list where we trim (so it was readable on selection). It would also make it easier to edit the protocol (http -> https). I'll speak with @verdi to figure out how to move. I'm mostly worried by the perf impact of option 2.

(In reply to Marco Bonardo [:mak] from comment #7)

It would also make it easier to edit the protocol (http -> https).

We generally don't optimize for that. E.g. to go from http to https on a loaded page, you have to copy and paste the URL to get http://, or manually type the entire protocol. I don't think this case should work any differently, ideally.

ok, so Verdi wants us to keep trimming, most browsers are trimming. I got an half idea on how to avoid the perf problem that I must investigate.

https://hg.mozilla.org/mozilla-central/rev/c1d93d736e13

🙏 Thank you for fixing this in time for the beta release!