New autofill threshold doesn't work well with redirects

VERIFIED FIXED in Firefox 62

Status

()

enhancement
P1
normal
VERIFIED FIXED
Last year
9 months ago

People

(Reporter: mak, Assigned: mak)

Tracking

unspecified
mozilla62
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox62 verified)

Details

(Whiteboard: [fxsearch])

Attachments

(1 attachment)

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.
Flags: qe-verify?
QA Contact: gwimberly
Assignee: nobody → mak77
Status: NEW → ASSIGNED
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.
Per discussion in Bug 1461753
Flags: qe-verify? → qe-verify+
Blocks: 1464154
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?
(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.
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 on attachment 8980119 [details]
Bug 1463132 - New autofill threshold doesn't work well with redirects.

https://reviewboard.mozilla.org/r/246272/#review253778
Attachment #8980119 - Flags: review?(adw) → review+
Pushed by mak77@bonardo.net:
https://hg.mozilla.org/integration/autoland/rev/2c0e0933f959
New autofill threshold doesn't work well with redirects. r=adw
https://hg.mozilla.org/mozilla-central/rev/2c0e0933f959
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
: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.
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.
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?
Flags: needinfo?(mak77)
Flags: needinfo?(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.
Flags: needinfo?(mak77)
Flags: needinfo?(adw)
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
Status: RESOLVED → VERIFIED
Flags: qe-verify+
See Also: → 1493543
You need to log in before you can comment on or make changes to this bug.