Closed Bug 1521702 Opened 8 months ago Closed 7 months ago

Hook up autofill with URL canonization


(Firefox :: Address Bar, enhancement, P2)




Firefox 67
Tracking Status
firefox67 --- fixed


(Reporter: dao, Assigned: adw)


(Blocks 1 open bug)



(1 file, 1 obsolete file)

Assignee: nobody → adw
  • Try to canonize all result types that aren't otherwise handled in the case statement. If canonization fails, then just fall back to the URL previously returned by UrlbarUtils.getUrlFromResult(). (Maybe we should only be doing this for URL results instead of all other results?)

  • When the first result is picked and the input autofilled a value, use the last search string as the value to canonize.

  • For search results, use the autofill value to canonize if there is one.

Attachment #9040943 - Attachment is obsolete: true

This is based on

I'll request review after that's reviewed.

I just hit a problem with canonization due to the behavior in handleCommand, in particular:

// Use the selected result if we have one; this should always be the case
// when the view is open.
let result = this.view.selectedResult;
if (result) {
  this.pickResult(event, result);

Well, this is not the case, canonization can transform "example/foo" in "", it doesn't only affect autofill.
Either we expand the reach of this added code to also handle other results, or we invert the logic and check canonization first, before pickResult.

note browser_canonizeUrl doesn't work correctly ATM, because we don't have the EventBufferer... I found that problem after implementing it (I have it running locally, but failing a couple tests due to actual bugs/misses)

we could make pickResult a pass-through... Something like:

let where = openWhere || this._whereToOpen(event);
let value = this.pickResult(event, result, where, openParams);
if (!value) {
    // pickResult has handled the load.

let url = this._maybeCanonizeURL ...

I think this would look and work more similarly to the old urlbar.

Blocks: 1512648

You're right about the problem. We only check canonization for search results right now, and then the patch adds autofill results. But it could apply to any type of result.

One thing that I don't like about the legacy implementation is that it checks event.ctrlKey in order to determine whether canonization should maybe happen, and then canonization checks event.ctrlKey again. It would be nice to have the canonization logic in one place and not rely on a "pre-check" like that.

So it seems like your solution of checking canonization first is a good idea. If pickResult is a pass through, then it would need to determine whether canonization should happen, only to call _maybeCanonizeURL later after pickResult returns, which would be splitting the logic in two places again.

Sure, it's just matter of deciding which architecture to follow. pickResult is also used by the mouse picks, so if it'd become pass-through we'd need a third method to actually handle the load (so handleCommand for keys, pickResult for mouse, prepareLoad for both?). If we move canonization first we have to pay some attention in pickResult to not override values set by canonization.

See Also: → 1526597
Pushed by
Hook up autofill with URL canonization. r=dao
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67
You need to log in before you can comment on or make changes to this bug.