1735534 - cannot turn off "did you mean to go to..." web search result

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[hal]

Attachment: Screen Shot 2021-10-13 at 5.51.01 AM.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

Do a simple firefox search for a single word like "snl"

Actual results:

At the top of the result page there is a on line dialog box saying something like "Did you mean to go to http://snl/" with a "yes take me too..." button to its right.

Expected results:

Normal search results without this extra dialog box. This has not appeared in firefox until the last several weeks. There is no apparent way to turn it off. Web searches turn up lots of long suggestions about fiddling with dns settings or resetting modems or other nonsense (and I do know what dns is - the point is that there is no apparent way to revert to the previous behavior where this did not appear, and that is the fix that is needed.) Please disable this by default or at least provide a simple, transparent way to disable it. It is not acceptable as-is, and descriptions of how to fiddle with internet or dns configurations are not appropriate either.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking: DNS' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Valentin Gosu [:valentin] (he/him)]

You can turn of that by going to about:config and setting browser.urlbar.dnsResolveSingleWordsAfterSearch to 0
Gijs, has there been any change to the feature recently?

Comment 3

[:Gijs (he/him)]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #2)

You can turn of that by going to about:config and setting browser.urlbar.dnsResolveSingleWordsAfterSearch to 0
Gijs, has there been any change to the feature recently?

I don't think so - Marco?

I suspect that the user's ISP and/or DNS server is providing these "DNS results", and this is basically bug 728670 / bug 1333191. Perhaps the DNS server changed? Some ISPs also allow disabling this feature on their end, so it's possible that changed, too.

It's worth noting that getting a detection here right is non-trivial; chrome used to have one that made a bunch of DNS queries, and at some point that stuff was a significant proportion of global DNS traffic, cf https://arstechnica.com/gadgets/2020/08/a-chrome-feature-is-creating-enormous-load-on-global-root-dns-servers/ . We wouldn't want to make the same mistake.

Comment 4

[Marco Bonardo [:mak]]

No, nothing changed yet.
The only pending work is Bug 1642623, where we'd like to introduce an heuristic to detect when the user is on an intranet, and only in that case enable this feature.
Bug 728670 is also still open, though as Gijs pointed out there's pitfalls there, indeed the Chromium team is about to disable that detection completely in https://bugs.chromium.org/p/chromium/issues/detail?id=1090985, and it looks like they are also disabling the "did-you-mean-to-go-to" with it. But allowing enterprise to re-enable it through policies.
They also point out in the future they could re-enable the feature for all users through an heuristic, that more or less sounds like the one we discussed in Bug 1642623, trying to detect if the user is on an intranet.

Honestly, we could do the same, and set browser.urlbar.dnsResolveSingleWordsAfterSearch to 0 by default.
We already have browser.fixup.dns_first_for_single_words that pretty much covers enteprise needs (pass through dns before searching), and whoever is working with intranet could flip browser.urlbar.dnsResolveSingleWordsAfterSearch easily.
At this point the feature is annoying for non technical users (and doesn't help them get rid of itself), while technical users can either type the protocol or flip the pref, that is something they are likely able to do.
Long term we could try to improve intranet detection, and flip the pref to 1 once we are satisfied with the result of it. Of course, the risk is that work will be idle for years if nobody assigns resources to it.

I think, modulo a PM heads-up, the decision is up to us.

Comment 5

[Marco Bonardo [:mak]]

Another option may be to add a "don't show this again" checkbox to the notification that users can click to disable the feature forever. The problem I see with that though, is that a good chunk of users prefer not touching things they don't understand. We had that problem with the search suggestions opt-in, where many users kept using the browser with that visible bar stealing up content space, and not touching it because they could not understand whether it was useful or not, or if they may need it in the future.

Comment 6

[:Gijs (he/him)]

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

Honestly, we could do the same, and set browser.urlbar.dnsResolveSingleWordsAfterSearch to 0 by default.
We already have browser.fixup.dns_first_for_single_words that pretty much covers enteprise needs (pass through dns before searching), and whoever is working with intranet could flip browser.urlbar.dnsResolveSingleWordsAfterSearch easily.
At this point the feature is annoying for non technical users (and doesn't help them get rid of itself), while technical users can either type the protocol or flip the pref, that is something they are likely able to do.

This sounds OK to me, though I agree we need to give PM a heads-up. Can you take point on this?

Comment 7

[Marco Bonardo [:mak]]

Ok, I'll write a doc explaining the feature, problems, workarounds and our suggestion, then ask you to have a look before presenting it.

Comment 8

[Marco Bonardo [:mak]]

I'll ask Natalie first and then we can invole a different PM if there's a better fit.

Comment 9

[Marco Bonardo [:mak]]

Gijs, Valentin, if you have suggestions about the proposal I linked, please leave comments on it. That's the standard format we use in the SNT team, and for now I submitted it to Natalie for our backlog grooming.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:adw, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 11

[Marco Bonardo [:mak]]

let' use backlog for now, we have a proposal filed for PM approval.

Comment 13

[James Teow [:jteow]]

Attachment: Bug 1735534 - Set browser.urlbar.dnsResolveSingleWordsAfterSearch to 0 by default - r?mak

Comment 14

[James Teow [:jteow]]

Attachment: data-request.md

Hi :chutten (or data reviewer), I'd like to request a data review.

Comment 15

[Chris H-C :chutten]

Comment on attachment 9281546 [details]
data-request.md

DATA COLLECTION REVIEW RESPONSE:

Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes.

Is there a control mechanism that allows the user to turn the data collection on and off?

Yes. This collection is Telemetry so can be controlled through Firefox's Preferences.

If the request is for permanent data collection, is there someone who will monitor the data over time?

Yes, James Teow is responsible.

Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 2, Interaction.

Is the data collection request for default-on or default-off?

Default on for all channels.

Does the instrumentation include the addition of any new identifiers?

No.

Is the data collection covered by the existing Firefox privacy notice?

Yes.

Does the data collection use a third-party collection tool?

No.

---

Result: datareview+

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d5ef7ee3de51
Set browser.urlbar.dnsResolveSingleWordsAfterSearch to 0 by default - r=mak

Comment 17

[Sandor Molnar[:smolnar]]

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

Comment 18

[James Teow [:jteow]]

Attachment: Bug 1735534 - Disable dnsResolveSingleWordsAfterSearch in UrlbarPrefs - r?mak

I did not realize there was another instance of this pref defined elsewhere.

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5f37ca2876e2
Disable dnsResolveSingleWordsAfterSearch in UrlbarPrefs - r=mak

Comment 21

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/5f37ca2876e2

Comment 22

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Hello,
I couldn't reproduce this issue on Firefox 103.0(build ID: 20220718155818) on Ubuntu 22.04 with browser.urlbar.dnsResolveSingleWordsAfterSearch set to 1. Are there any specific settings/configs changes that need to be made prior to testing in order to reproduce this bug?
Thank you.

Comment 23

[James Teow [:jteow]]

The easiest way to reproduce it locally is to modify your hosts file and add a word that shouldn't normally map to an IP address.

So for Linux, what I'd do is open a terminal and run:

sudo nano /etc/hosts

Where it prompts you to enter your password, and then opens up the hosts file with the Nano text editor.

You'll see a list of entries containing IP addresses paired with hostnames. Create a new line and add something like so:

127.0.0.1 exampleword

Then save the changes. Then try rebooting Firefox.

When you type exampleword in the URL bar while browser.urlbar.dnsResolveSingleWordsAfterSearch is 1, you should see a popover that says something like, "did you mean to go to http://exampleword?"

Comment 24

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Thank you for your help James, appreciate it!
I managed to reproduce this issue following the steps from Comment 23 on Firefox 103.0(build ID: 20220718155818) on Ubuntu 22.04. Verified as fixed on Firefox RC 104.0(build ID: 20220815150936) and Nightly 105.0a1(build ID: 20220816095503) on Ubuntu 22.04, macOS 12 and Windows 10. browser.urlbar.dnsResolveSingleWordsAfterSearch is now by default 0 on both Firefox 104.0 and Nightly 105.0a1.