1642435 - Go links stopped working in the latest nightly. They redirect to search engine instead.

Status: RESOLVED WORKSFORME

(Firefox :: Address Bar, defect)

Description

Attachment: Shot 2020-06-01 at [e-mail]

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

Steps to reproduce:

Google corp uses Go links for internal redirects. The public version of that is here at https://www.golinks.io/

Around May 28th Nightly update we got reports of go links now not working.
Maybe https://bugzilla.mozilla.org/show_bug.cgi?id=1634650 caused it?

Proxy config: [redacted] (also, see screenshot)

Actual results:

go/foo now goes searches for 'go/foo' instead of going to the redirect url through the proxy config.

Reproduced on Nightly 78.0a1 (2020-06-01) (64-bit) on MacOS

Expected results:

go/foo should go to the url it's meant for in the proxy.

example go/foo -> foo.internal.example.com

Comment 1

[Sagar]

Additional repro case:

URL go/foo now goes searches for 'go/foo'
URL http://go/foo does work as intended and redirects as per proxy config.

Comment 2

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

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

Comment 3

[Mark Banner (:standard8)]

Probably a result of bug 1398567.

Comment 4

[Mathew Hodson]

Does it work on other browsers? Chrome and Edge behave them same as Firefox 78 from what I see.

You can force a visit by appending a slash at the end since bug 1636583. Does that work?

Comment 5

[Marco Bonardo [:mak]]

You can add a boolean pref browser.fixup.domainwhitelist.go set to true in about:config.
If you are in an enterprise with a private DNS server, you can also use browser.fixup.dns_first_for_single_words = true, and we'll always go through the dns.

Do other browsers work differently? The website seems to suggest using an add-on

Comment 6

[Sagar]

Attachment: Shot 2020-06-02 at 09.01.38.png

After setting the MacOS level config...

Comment 7

[Sagar]

Attachment: Shot 2020-06-02 at 09.02.32.png

...Edge does do go/link redirect after I set preferences

Comment 8

[Sagar]

@mak browser.fixup.domainwhitelist.go wont help me much because go isn't the only keyword they redirect with. there's also c/foo for calendar of user foo, for example. There's a litany of these.

browser.fixup.dns_first_for_single_words might work out, but since it worked without a flag switch before, is this considered a regression?
And will that flag go away anytime soon? (If we do start relying on that workaround...)

Especially since other browsers (Edge/Chrome) work, but yeah Safari doesn't (redirects to search unless I append a / like c/foo/)

Comment 9

[Marco Bonardo [:mak]]

Why did you mark this as security sensitive?

(In reply to Sagar from comment #8)

@mak browser.fixup.domainwhitelist.go wont help me much because go isn't the only keyword they redirect with. there's also c/foo for calendar of user foo, for example. There's a litany of these.

You can create how many prefs as you wish of course, and I'd suggest using an autoconfig file to avoid doing that manually. Of course in an enterprise environment with many intranet domains not using suffixes, it's simpler to rely on the dns...

browser.fixup.dns_first_for_single_words might work out, but since it worked without a flag switch before, is this considered a regression?
And will that flag go away anytime soon? (If we do start relying on that workaround...)

It's not a regression, we changed the behavior on purpose because the old behavior was confusing users, and was also not coherent with any other browser.
The browser.fixup.dns_first_for_single_words flag won't go away, it's largely used by enterprises.

Especially since other browsers (Edge/Chrome) work, but yeah Safari doesn't (redirects to search unless I append a / like c/foo/)

From Firefox 78 you can also force a visit appending a slash, though with one of the previous solutions that won't be necessary.

Comment 10

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

Set release status flags based on info from the regressing bug 1398567

Comment 11

[Sagar]

If that flag isn't going away anytime, would it be possible to surface it in about:config as default false? I think right now we have to create anew which feels fleeting.

Also, as you mentioned about the enterprise requirement, is there documentation about that flag? (I couldn't find much)

Marking as security was accidental. I'm trying to edit the original bug description to remove the pac file URL but couldn't figure it out. And now I can't remove it from security either.

Thanks Marco!

Comment 12

[Sagar]

Woah. Thanks:Gijs

Comment 13

[Marco Bonardo [:mak]]

(In reply to Sagar from comment #11)

If that flag isn't going away anytime, would it be possible to surface it in about:config as default false? I think right now we have to create anew which feels fleeting.

Yes, we can add it to firefox.js so it appears, I don't see why it wasn't originally, it doesn't need to be an hidden pref.

Also, as you mentioned about the enterprise requirement, is there documentation about that flag? (I couldn't find much)

Policies are documented here:
https://github.com/mozilla/policy-templates/blob/master/README.md
For this specific one see under the Preferences section.

Comment 14

[Marco Bonardo [:mak]]

I filed bug 1643259 to unhide the pref, I will mark this bug as WORKSFORME because anyway we provide ways to configure the behavior that should cover the needs. Please let us know if you have further concerns.

Comment 15

[Sagar]

This is great. Thanks for your support and communication

Comment 20

[Aram Akhavan]

It's not a regression, we changed the behavior on purpose because the old behavior was confusing users, and was also not coherent with any other browser.
Can you elaborate? How was the old behavior confusing users? Should Mozilla simply "fall in line" because other browsers are doing things a certain way?

As a "power user" it's frustrating to see a policy of changing things to break widely-used paradigms (i.e. go links) because of confusion among some users, which I have a real hard time believing.

Yes, I realize it can be worked around with config, but should we have to? I would argue it hurts adoption more than helps.

Comment 21

[Marco Bonardo [:mak]]

(In reply to Aram Akhavan from comment #20)

Yes, I realize it can be worked around with config, but should we have to? I would argue it hurts adoption more than helps.

There's also a notification bar if you just type "go" and Firefox detects "go" can be resolved by the dns. And it does all the prefs setting for you.
We'll likely also provide a way for WebExtensions to register suffixes or domains, so in the end it may become just matter of installing a trivial add-on.

Note the most common case for users is that they won't use these domains, so this is not about breaking everyone to solve confusion among few users, but it's the opposite, doing the most commonly expected thing for most users, while few power users unfortunately have to configure the product, but that's something they know how to do.

Achieving both is not possible, it would require doing continuous DNS requests that would hurt privacy and, in some cases, performance.

Comment 22

[:Gijs (he/him)]

Should we consider listing go in the prefs by default, if that particular hostname is so common?

Comment 23

[Marco Bonardo [:mak]]

We don't know how common it is, and I'm prone to say no, because otherwise we need a policy to say why we add "go" and not others that could be equally important to another subset of users, and then why not .crypto and .eth or suffixes from other TLD providers?
Everyone of course will have their own preference and beliefs about what matters, for now my policy is that it must be specc-ed in a Web standard RFC (that is why we added localhost, .local, .internal and friends).
If we find for users it is too complicate to flip prefs or install an add-on (once we have that support), I'd rather suggest we detect the use of "http(s)//unknown-domain/something" and automatically add the domain/suffix, instead of hardcoding things that would end up making someone happy and someone sad.

Comment 24

[Aram Akhavan]

By the way, go links do work on Edge 44...