Open Bug 1635299 Opened 5 years ago Updated 4 years ago

Autofilling on focus due to retained results is surprising

Categories

(Firefox :: Address Bar, defect, P3)

defect
Points:
3

Tracking

()

People

(Reporter: adw, Unassigned)

References

(Blocks 1 open bug)

Details

STR

  1. Enable session restore
  2. Visit foodnetwork.com
  3. Open a new tab
  4. Type "foo", it should autofill to foodnetwork.com
  5. Hit backspace once to remove the autofilled part
  6. Optional: Hit Esc once or unfocus the urlbar, which might help to emphasize the problem, i.e., that you quit Firefox with "foo" in the urlbar, not foodnetwork.com
  7. Restart
  8. Focus the urlbar

foodnetwork.com is autofilled, which imo is surprising and not desired.

We could fix the call path for this particular case so we pass false for allowAutofill. However, UrlbarInput.startQuery defaults allowAutofill to true, but afaict we only want it to be true when startQuery is called due to user input. So I think we should fix this by defaulting it to false.

This has been annoying me while working on bug 1398416.

Another simpler way this happens:

  1. Enable session restore
  2. Visit foodnetwork.com
  3. Open a new tab
  4. Type "foo", it should autofill to foodnetwork.com
  5. Click outside the urlbar, the input value changes to "foo"
  6. Click back inside the urlbar, the input value changes to foodnetwork.com with an autofill heuristic result

I think we should respect whatever's in the input. So either:

  • We leave foodnetwork.com as the value when you blur or restart with session restore, and then we autofill foodnetwork.com on focus (or just show a visit heuristic, no need for autofill at that point)
  • Or we leave "foo" as the value on blur/restore but don't autofill on focus

Either way, we leave what you typed in the input when you focus it.

This is more work than just defaulting allowAutofill to false, so I'll unassign myself. In particular I ran into browser_retainedResultsOnFocus.js, a very thorough test that made me realize this is more complex than I thought.

Assignee: adw → nobody
Status: ASSIGNED → NEW
Iteration: 78.1 - May 4 - May 17 → ---
Points: 1 → 3
Blocks: 1630275
Depends on: 1579002
Summary: Autofill can surprisingly happen after session restore when focusing the urlbar for the first time → Autofilling on focus due to retained results is surprising

we should pay attention to not regress autofill of retained results when we fix this.

(In reply to Drew Willcoxon :adw from comment #1)

  1. Visit foodnetwork.com
  2. Open a new tab
  3. Type "foo", it should autofill to foodnetwork.com
  4. Click outside the urlbar, the input value changes to "foo"
  5. Click back inside the urlbar, the input value changes to foodnetwork.com with an autofill heuristic result

This is the expected effect of retained results, we return to the previous state.

I think we should respect whatever's in the input. So either:

  • We leave foodnetwork.com as the value when you blur or restart with session restore, and then we autofill foodnetwork.com on focus (or just show a visit heuristic, no need for autofill at that point)
  • Or we leave "foo" as the value on blur/restore but don't autofill on focus

I disagree, the scope of retained results is to restore the previous abandoned search state, if we were autofilling, we should be autofilling.
If we put foodnetwork.com we basically broke user input, I typed foo, I want to continue from there, if instead we remove autofill, the heuristic is broken, so I read foo, press enter and we go to foodnetwork.com instead of searching foo.

Either way, we leave what you typed in the input when you focus it.

We do, the autofilled part can always be backspaced/deleted, as usual.

Now, I'm not sure why we autofill on session restore, probably it's because we re-query if we have no cache of results.

I think the real bug here is that we restore results for a session-restored tab. but the only simple fix that comes to my mind is to only restore results if we have those in the cache. Verdi wanted us to restore regardless of having results cache or not.

You need to log in before you can comment on or make changes to this bug.