UnifiedComplete disables inline autocomplete if urlbar behavior is not the default

RESOLVED FIXED in mozilla34

Status

()

Toolkit
Places
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: ttaubert, Assigned: mak)

Tracking

({regression})

Trunk
mozilla34
regression
Points:
5
Dependency tree / graph
Bug Flags:
firefox-backlog +
in-testsuite +
qe-verify -

Firefox Tracking Flags

(firefox34 affected)

Details

Attachments

(3 attachments, 1 obsolete attachment)

Typing in "spi" I see Awesomebar results for "spiegel.de" but the URL isn't autocompleted. Turning off UC via its pref makes it work again.
Created attachment 8462558 [details]
Screenshot of missing autocomplete
Created attachment 8462559 [details]
Screenshot with UC pref'ed off
Can you please add this to the iteration, Marco? Thanks!
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Iteration: --- → 34.1
Flags: needinfo?(mmucci)
Points: --- → 3
ehr, let's say 5, since we might want a test for whatever this bug is.
Points: 3 → 5
Seems to be caused by setting browser.urlbar.default.behavior=1.
Added to Iteration 34.1
QA Whiteboard: [qa?]
Flags: needinfo?(mmucci)
that is basically dut to the fix for bug 810930 I inserted during the rewrite. The current behavior is the expected one because when the default behavior changes we cannot tell where the autoFill entry comes from (history, bookmarks, other?).
So what we do is disable autoFill to avoid ignoring the user's choice about what to suggest.

On the other side this might be surprising to users who got results so far and suddenly don't anymore.
We should at a minimum clarify in the prefs that choosing history/bookmarks disables autoFill. Otherwise we might disable autoFill only when results are restricted to bookmarks.
When they are restricted to history, it's unlikely to be an issue, if it's a bookmark is very likely to be visited, and we also only autoFill typed entries.

So my suggestion would be:
1. still autoFill if results are restricted to history
2. specify in the prefs that choosing Bookmarks will disable autoFill
Summary: UnifiedComplete breaks inline autocomplete → UnifiedComplete disables inline autocomplete if urlbar behavior is not the default
(In reply to Marco Bonardo [:mak] from comment #7)
> So my suggestion would be:
> 1. still autoFill if results are restricted to history
> 2. specify in the prefs that choosing Bookmarks will disable autoFill

That sounds indeed like a fine solution to me.
QA Whiteboard: [qa?] → [qa+]
status-firefox34: --- → affected
QA Contact: alexandra.lucinet
QA Contact: alexandra.lucinet → andrei.vaida

Updated

3 years ago
QA Whiteboard: [qa+] → [qa-]
Unassigning QA, this will be well covered by automated tests.
QA Contact: andrei.vaida
Created attachment 8464335 [details] [diff] [review]
patch v1
Attachment #8464335 - Flags: review?(ttaubert)

Updated

3 years ago
Flags: firefox-backlog+
Comment on attachment 8464335 [details] [diff] [review]
patch v1

Review of attachment 8464335 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM. The extensive tests should really cover everything afaict.
Attachment #8464335 - Flags: review?(ttaubert) → review+
Created attachment 8466220 [details] [diff] [review]
patch v2

since I'm landing foreign_count at the same time, I'm already fixing bug 1045924 here by making the queries use it.
Attachment #8464335 - Attachment is obsolete: true
https://hg.mozilla.org/integration/fx-team/rev/d0d6a897c568
Depends on: 1017502
Flags: in-testsuite+
Target Milestone: --- → mozilla34
https://hg.mozilla.org/mozilla-central/rev/d0d6a897c568
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Blocks: 751709
Setting qe-verify- for this fix since it's already covered by automated testing. Marco, if there's something manual QA can look at here, please flip the flag.
Flags: qe-verify-
You need to log in before you can comment on or make changes to this bug.