Open Bug 1663577 Opened 4 years ago Updated 18 days ago

Editing URI in URI bar and pressing Enter goes to search instead of loading new URI

Categories

(Firefox :: Address Bar, defect, P3)

80 Branch
defect
Points:
3

Tracking

()

People

(Reporter: ed, Unassigned)

References

Details

(Keywords: papercut, Whiteboard: [snt-scrubbed][search-papercut])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

Browse to a URI on the local network, like
http://myserver/mystuff/ABC-123?
Firefox loads the page directly and displays an abbreviated URI in the location bar:
myserver/mystuff/ABC-123?
Now click in the location bar. The whole text is selected. Press right-arrow to clear the selection and put the caret at the end of the text. Press backspace to delete the final ? character. The location bar now shows
myserver/mystuff/ABC-123
Press Enter.

Actual results:

Pressing Enter runs a Google search using the edited URI as the search string.

Expected results:

When you've edited a URI and press Enter, it should go to that new URI. This was always the behaviour of Firefox (and every other browser) in the past. Editing a URI and then using it as a search string is a rather uncommon operation and should not be the default.

It seems to happen when viewing local network sites that don't have a fully qualified hostname. I guess there is some guessing of whether the string looks like a URI or looks like a search term. But Firefox should know that if it's currently showing a page, and the user has edited the URI (not deleted it and pasted in a whole new piece of text), the result of that edit is still a URI.

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

Component: Untriaged → DOM: Editor
Product: Firefox → Core
Component: DOM: Editor → Address Bar
Product: Core → Firefox

Yeah, we could be smarter about editing known URLs. In the meantime, you can create a boolean pref named browser.fixup.domainwhitelist.NAME and set it to true, where NAME in your case would be myserver. If you're running a DNS on your local network, you can also set browser.fixup.dns_first_for_single_words to true. See also bug 1642435.

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
See Also: → 1642435

we should probably run the dns search not just for single words, but for strings looking like uris, extracting the domain part.
Then you'd get a "did you mean to go to" dialog that allows to setup the pref with a simple click.

Keywords: papercut
Points: --- → 3
See Also: → 1698463

James[:jteow] is working on moving "did you mean to go to" dialog to be off/disabled by default.

It might not be worth resolving this bug until the work from James is done. This will provide telemetry that would help us determine if it’s worth fixing this bug so we can identify if users are re-enabling the "did you mean to go to" dialog.

There is a current work around:

  • First workaround is in comment 2
  • Second work around -- There is also browser.fixup.dns_first_for_single_words pref that a user could flip to workaround this bug, if that pref is true we always hit the DNS server BEFORE making a search (though navigation will be slower).
Whiteboard: [snt-scrubbed][search-papercut]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:adw, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(adw)
Flags: needinfo?(adw)

Hi, could I ask you to revisit this bug? Two years ago it was blocked on some other work.

My suggestion is that editing an existing URI be treated differently from typing in some new text. If the address bar shows a URI, and you delete some characters from the end, it shouldn't stop being a URI and become a search term instead.

(I can confirm it still occurs with 127.0b1 so the "version" field on the bug can be updated)

we are working on bugs that should reduce the likelihood of this to happen, by untrimming the url on edit. A solution is already active in Nightly, will probably make Release in Fx 129 (though that may be delayed further in case of stability issues).

You need to log in before you can comment on or make changes to this bug.