1463132 - New autofill threshold doesn't work well with redirects

Status: VERIFIED FIXED

(Toolkit :: Places, enhancement, P1)

Description

[Marco Bonardo [:mak]]

This is a case I've hit in the last days, involving maps.google.com
This usually redirects to www.google.com/maps, and as such it has a low frecency, because it's a redirect and in general we care more about the final target.
Due to that redirection, it doesn't pass the threshold and doesn't autofill anymore.

Maybe if the visit is typed and it's a redirect source, we should still use the typed bonus.

P1 to investigate this.

Comment 1

[Marco Bonardo [:mak]]

Attachment: Bug 1463132 - New autofill threshold doesn't work well with redirects.

Review commit: https://reviewboard.mozilla.org/r/246272/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/246272/

Comment 2

[Marco Bonardo [:mak]]

The patch changes frecency so that we still use a low bonus for permanent redirects, and for temporary redirects that are not typed. Temporary redirects that are typed will get the typed bonus.

Comment 3

[u554753]

Per discussion in Bug 1461753

Comment 4

[Marco Bonardo [:mak]]

Comment on attachment 8980119 [details]
Bug 1463132 - New autofill threshold doesn't work well with redirects.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/246272/diff/1-2/

Comment 5

[Drew Willcoxon :adw]

I'm looking at the patch now, but I wonder whether we should do this for all typed redirects, even permanent.  I think so.  If the user has the habit of typing foo.example.com to get to example.com (foo.example.com permanently redirects to example.com), I don't think it's Firefox's place to try to break that habit, which is what it would effectively be doing.  What do you think?

Comment 6

[Marco Bonardo [:mak]]

(In reply to Drew Willcoxon :adw from comment #5)
> I'm looking at the patch now, but I wonder whether we should do this for all
> typed redirects, even permanent.  I think so.  If the user has the habit of
> typing foo.example.com to get to example.com (foo.example.com permanently
> redirects to example.com), I don't think it's Firefox's place to try to
> break that habit, which is what it would effectively be doing.  What do you
> think?

My thought is that the intention of the site owner is to move people away from that domain, it's possible it's going away or being replaced. So maintaining the users habits on it may not be a great idea.

Comment 7

[Drew Willcoxon :adw]

I understand and it makes sense, but I doubt most users even notice redirects, so they won't know to switch to typing the new URL.  They'll just see that this URL that they've been typing into the urlbar -- and successfully visiting -- never gets autofilled.

But I can r+ this patch as is and we can think about that more.

Comment 8

[Drew Willcoxon :adw]

Comment on attachment 8980119 [details]
Bug 1463132 - New autofill threshold doesn't work well with redirects.

https://reviewboard.mozilla.org/r/246272/#review253778

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2c0e0933f959
New autofill threshold doesn't work well with redirects. r=adw

Comment 10

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/2c0e0933f959

Comment 11

[Paul]

:adw To add to your point about permanent redirects, you're right, and there are a few important use cases where the redirect target isn't useful.

1. Pages that don't allow you to visit directly, but work fine via a redirect. E.g. some login and logout pages, and also links that encode a temporary load balancer cookie (I'm looking at you, Demonoid).
2. Pages whose redirected form isn't what you want. E.g. if you prime the history with https://en.wikipedia.org/wiki/ you can just type "wi", down arrow, and then start typing to append the page you're interested in directly to the address. This workflow is the bee's knees for people who prefer to go directly to a resource instead of searching.

Comment 12

[Marco Bonardo [:mak]]

we're not optimizing for edge-cases, anyway.

(In reply to Paul from comment #11)
> 1. Pages that don't allow you to visit directly, but work fine via a
> redirect. E.g. some login and logout pages, and also links that encode a
> temporary load balancer cookie (I'm looking at you, Demonoid).

It sounds unlikely to be related to autofill, unless that page is the index page for a domain.

> 2. Pages whose redirected form isn't what you want. E.g. if you prime the
> history with https://en.wikipedia.org/wiki/ you can just type "wi", down
> arrow, and then start typing to append the page you're interested in
> directly to the address. This workflow is the bee's knees for people who
> prefer to go directly to a resource instead of searching.

also sounds unlikely to involve an autofill, indeed your example is a normal pick from history.

These cases are well covered by Adaptive history, imo.

Comment 13

[u554753]

Asking for clarification here to be able to verify it.

Typing in maps.google.com and hitting return several times so it passes the autofill threshold, but because it redirects to google.com/maps, the bonus on the latter one is so low that I need to enter the maps.google.com link in many times for the latter to eventually hit the threshold. Is my understanding correct on this?

Comment 14

[Drew Willcoxon :adw]

Yes, that's right.  maps.google.com is a temporary and typed redirect "source", so its frecency gets boosted, which is what the patch did.  google.com/maps is a redirect "target", so its frecency remains low, and the patch didn't change that behavior.

Comment 15

[u554753]

Thanks for the clarification.

Verified on the newest Nightly (62.0a1) 06-07-2018 with the following OS: Windows 10 x64, Mac OSX 10.11, and Ubuntu 18.10 x64
Version: 62.0a1
Build ID: 20180607100059