1050943 - Investigate whether going directly to search suggestion URL violates search provider TOS

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect, P5)

Description

[Robert (rrayborn, he/him)]

Not sure if this is a known issue but clicking on some Google search results is taking me to the local domain http://<search-term>

Steps to reproduce:
1) Type in a search term to the URL bar something. eg: "fac"
2) Click a single word Google result that ISN'T the first result. eg: "facebook"
  (For some reason it works fine for the first result, but only the first result)
3) Fennec will take you to the local server address of the search result.  eg:
"http://facebook/"

This was reproduced dozens of times with terms like
 * type:"dog"  click:"dogecoin"  resolves to "http://dogecoin/"
 * type:"cat"  click:"catfish"   resolves to "http://catfish/"
 * type:"toro" click:"toronto"   resolves to "http://toronto/"
 * type:"fac"  click:"facebook"  resolves to "http://facebook/"
 * type:"bar"  click:"bart"      resolves to "http://bart/"
 * etc

Thanks

Comment 1

[Aaron Train [:aaronmt]]

This is not related to the new search activity.

Comment 2

[Brian Nicholson (:bnicholson)]

Rob, can you confirm whether this happens in the latest Nightly (https://nightly.mozilla.org)?

Comment 3

[Robert (rrayborn, he/him)]

Brian - This does not effect Nightly, but it does effect Beta.

Comment 4

[Brian Nicholson (:bnicholson)]

(In reply to Rob from comment #3)
> Brian - This does not effect Nightly, but it does effect Beta.

Looking at [1], isSearchQuery does a URL load rather than a search if isSearchQuery() returns false. We pass false to use as the default if we can't determine whether the query is a URL or a search, which seems like a bug to me -- I always thought we defaulted to true (i.e., a search) there.

So what's happening is basically the same as typing a single word and hitting enter, which is fixed by bug 693808 (Fx33+).

[1] http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/home/SearchEngineRow.java#82

Comment 5

[Jared Wein [:jaws] (please needinfo? me)]

Is this fixed bug bug 693808? I think it is actually fixed by bug 1047607.

Comment 6

[Brian Nicholson (:bnicholson)]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #5)
> Is this fixed bug bug 693808? I think it is actually fixed by bug 1047607.

The candidates were bug 693808, bug 854305, bug 993705, and bug 1047607. Bug 693808 seemed like the logical choice since it's the real fix, and the other bugs are more about the workaround.

Comment 7

[Robert (rrayborn, he/him)]

I'm glad to see that this has been fixed for the majority of use-cases, but this being fixed as a side-effect of previous bugs can still lead to questionable behaviours:

1) We are still treating the 1st "suggestion" different from Google's other suggestions. If I type in "amazon.co" and click the 1st "suggestion" ("amazon.co") then it resolves to a Google search for "amazon.co".  Whereas if I click any other suggestion that would resolve isSearchQuery() to false I get the webpage (2nd result "amazon.com" goes to http://amazon.com).  At the very least we need to fix this inconsistent behaviour
2) If we are implying that auto-suggest is a search query, then IMO we should treat it as such.  If I type "amazon.co" and click "amazon.com" under a Google search branded element I expect to be taken to a search rather than being taken to the URL.  As a former AWS TAM (few years ago), ***I'm also guessing that using Google's auto-suggest and then going directly to a URL is a violation of there TOS unless we got a contractual exception.***

Reopening for now, LMK if you'd like me to file separate bugs or if my assumptions are not correct.

Thanks

Comment 8

[Robert (rrayborn, he/him)]

I was asked to change this to a "private" bug due to possible TOS concerns until we get resolution.

Thanks

Comment 9

[Brian Nicholson (:bnicholson)]

(In reply to Rob from comment #7)
> I'm glad to see that this has been fixed for the majority of use-cases, but
> this being fixed as a side-effect of previous bugs can still lead to
> questionable behaviours:
> 
> 1) We are still treating the 1st "suggestion" different from Google's other
> suggestions. If I type in "amazon.co" and click the 1st "suggestion"
> ("amazon.co") then it resolves to a Google search for "amazon.co".  Whereas
> if I click any other suggestion that would resolve isSearchQuery() to false
> I get the webpage (2nd result "amazon.com" goes to http://amazon.com).  At
> the very least we need to fix this inconsistent behaviour

The first suggestion corresponds to the user-entered query, so it's assumed that the user always wants to do a search when clicking this suggestion (otherwise, they would just hit enter/Go from the URL bar). In other words, if I've fully typed "gmail.com", the only reason I would tap the first suggestion would be if I wanted to search for it. If we were to use the same URL-following behavior for the first suggestion as we used for the remaining suggestions, that means it would be impossible for user to actually do a search for "gmail.com".

However, if I type "gmail." and see "gmail.com" as one of the suggestions, I most likely want to go to http://gmail.com. I agree this might seem inconsistent, but at the same time, the first suggestion has the search magnifier icon that differentiates from the rest, so I don't think it's unreasonable for them to have different behaviors.

> 2) If we are implying that auto-suggest is a search query, then IMO we
> should treat it as such.  If I type "amazon.co" and click "amazon.com" under
> a Google search branded element I expect to be taken to a search rather than
> being taken to the URL.  As a former AWS TAM (few years ago), ***I'm also
> guessing that using Google's auto-suggest and then going directly to a URL
> is a violation of there TOS unless we got a contractual exception.***

The vast majority of the time, the user will want to go to the suggested URL rather than do a search for that URL. We actually implemented this in the first place because people were entering "amazon.", clicking "amazon.com", then were getting annoyed at the indirection. Note that if you really wanted to do a Google search for "amazon.com", you could type "amazon.com" and click the user-entered suggestion as described above.

The point about violating Google's TOS is interesting, and I'm not sure whom to ask. CC'ing some people that may know.

Given the private change, I'm going to morph this bug to the second issue. Feel free to file a follow-up about the first issue, and UX can have a look.

Comment 10

[Robert (rrayborn, he/him)]

@Brian - I appreciate the thorough response.  Thanks for bringing me up to speed on the thought process.  It's clear that this behaviour has had adequate discussion so I won't file a bug for it.

Comment 11

[Jared Wein [:jaws] (please needinfo? me)]

This shouldn't need to be core-security

Comment 12

[Brad Lassey [:blassey] (use needinfo?)]

mconnor, can you weigh in here?

Comment 13

[Brad Lassey [:blassey] (use needinfo?)]

filter on [mass-p5]

Comment 14

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.