Closed
Bug 1498181
Opened 6 years ago
Closed 6 years ago
Set up initial methods for handling result selection in the new address bar architecture.
Categories
(Firefox :: Address Bar, enhancement, P1)
Firefox
Address Bar
Tracking
()
RESOLVED
FIXED
Firefox 64
| Tracking | Status | |
|---|---|---|
| firefox64 | --- | fixed |
People
(Reporter: standard8, Assigned: standard8)
References
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 file)
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 years 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 years 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)
|
||
Comment 3•6 years ago
|
||
Looks pretty good overall. I left some comments in phabricator.
Flags: needinfo?(dao+bmo)
|
||
Updated•6 years ago
|
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 years 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)
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 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/e7c817964e52
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
|
|
||
Updated•5 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•