New autofill threshold doesn't work well with redirects

VERIFIED FIXED in Firefox 62

Status

()

P1
normal
VERIFIED FIXED
6 months ago
a month ago

People

(Reporter: mak, Assigned: mak)

Tracking

unspecified
mozilla62
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox62 verified)

Details

(Whiteboard: [fxsearch])

Attachments

(1 attachment)

(Assignee)

Description

6 months ago
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)

Updated

6 months ago
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Comment hidden (mozreview-request)
(Assignee)

Comment 2

6 months ago
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+
Comment hidden (mozreview-request)
(Assignee)

Updated

6 months ago
Blocks: 1464154

Comment 5

6 months ago
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?
(Assignee)

Comment 6

6 months ago
(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

6 months ago
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

6 months ago
mozreview-review
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+

Comment 9

6 months ago
Pushed by mak77@bonardo.net:
https://hg.mozilla.org/integration/autoland/rev/2c0e0933f959
New autofill threshold doesn't work well with redirects. r=adw

Comment 10

6 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/2c0e0933f959
Status: ASSIGNED → RESOLVED
Last Resolved: 6 months ago
status-firefox62: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla62

Comment 11

6 months ago
: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.
(Assignee)

Comment 12

6 months ago
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)

Comment 14

5 months ago
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
status-firefox62: fixed → verified
Flags: qe-verify+

Updated

a month ago
See Also: → bug 1493543
You need to log in before you can comment on or make changes to this bug.