Set up initial methods for handling result selection in the new address bar architecture.

RESOLVED FIXED in Firefox 64

Status

()

enhancement
P1
normal
RESOLVED FIXED
6 months ago
a month ago

People

(Reporter: standard8, Assigned: standard8)

Tracking

(Blocks 4 bugs)

Trunk
Firefox 64
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox64 fixed)

Details

(Whiteboard: [fxsearch])

User Story

- The input / view should be responsible for managing:
-- if the mouse is right-clicked or if there's no url in the address bar.
-- routing of all one-off button commands, i.e. the section here should be part of the input/view: https://searchfox.org/mozilla-central/rev/80ac71c1c54af788b32e851192dfd2de2ec18e18/browser/base/content/urlbarBindings.xml#658-674

- The controller is responsible for managing:
-- telemetry logging
-- doing the actual opening of the selected result
-- handling searches / keyword openings

Attachments

(1 attachment)

(Assignee)

Description

6 months ago
In the new address bar architecture, we need some way of handling selection of results/entering via the address bar.

In the existing architecture, this is basically all routed through one handleCommand in urlbarBindings:

https://searchfox.org/mozilla-central/rev/80ac71c1c54af788b32e851192dfd2de2ec18e18/browser/base/content/urlbarBindings.xml#626-797

Per previous discussions, I think we should separate this out a bit. See the user story for the current theory on how this should separate.

I think we're likely to end up with multiple functions in the controller. I should have a patch up later today which will hopefully provide more context.
(Assignee)

Comment 1

6 months ago
The intent here is that the input/view deal with the handling of clicks/pressing enter, and the controller only deals with opening the required item.
(Assignee)

Comment 2

6 months ago
I've just attached something that is roughly the architecture I think we want. See the user story for some background to it.

The main intent here is to simplify & break up the existing handleCommand function across the input/view/controller, so that the various parts are more appropriately located.

There's plenty of TODO comments but I think most of those are for follow-ups - If we're happy with the architecture, then I'd suggest we could probably land as-is and fill them in as we go.

As it stands you can select a switch to tab result and you'll be taken there, or you can enter a url in the address bar, press enter and you'll visit that url.

Feedback welcome.
Flags: needinfo?(mak77)
Flags: needinfo?(dao+bmo)
Flags: needinfo?(adw)
Looks pretty good overall. I left some comments in phabricator.
Flags: needinfo?(dao+bmo)
Depends on: 1498553
Attachment #9016275 - Attachment description: Bug 1498181 - WIP Initial methods for handling result selection in the new address bar architecture. → Bug 1498181 - Initial methods for handling result selection in the new address bar architecture.
(Assignee)

Comment 4

6 months ago
Thanks for the feedback, Dao.

I've put this up for review, so dropping the need infos, but comments are still welcome (we can always address in follow-ups).
Flags: needinfo?(mak77)
Flags: needinfo?(adw)

Comment 5

6 months ago
Pushed by mbanner@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e7c817964e52
Initial methods for handling result selection in the new address bar architecture. r=dao

Comment 6

6 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/e7c817964e52
Status: NEW → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
Blocks: 1498748
(Assignee)

Updated

6 months ago
Blocks: 1500483
Depends on: 1509610
(Assignee)

Updated

5 months ago
No longer depends on: 1509610
Blocks: 1498553
No longer depends on: 1498553
You need to log in before you can comment on or make changes to this bug.