1235397 - Investigate merging the action row with the input field

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, defect, P3)

Description

[Marco Bonardo [:mak]]

Based on most common negative feedback about unified complete, looks like the action row is a little bit too much eyes catching/distracting. This makes sense also cause it should be oneline, but it's currently taking 2...

Regardless, I had a previous discussion with Stephen where he was asking if we could hide that entry and directly merge the action information in the input field, so for example instead of:
[porcupine_                      ]
| porcupine - Search with Google | (preselected)
| other results                  |
we get:
[porcupine_ - Search with Google  ]
| other results                   |

The default "Visit" action would get no hint (it's currently just a placeholder).

Now that we have a stable experience we could try to visually hide the heuristic entry and merge its information in the input field. Things should ideally keep working correctly since it's only a visual change. Tests will need some fixes.

Comment 2

[Marco Bonardo [:mak]]

I think Drew was/is investigating this, assigning just to have an idea of what's up.

Comment 4

[Drew Willcoxon :adw]

roc, could you please give me some advice on how I should implement this?  We want to have a string of uneditable, colored text in the urlbar that follows whatever you type, like "-- Search with Google", similar to how Safari's urlbar works.

I've started by looking at previous bugs that added domain highlighting and crossing out "https" for mixed-content sites, which you reviewed (bug 451833, bug 834830).  The use case here is more complex because the extra text must be present as you're typing, moving the caret, and making selections.

I added a new selection type and am able to style it.  The problem I'm facing now is the caret.  Ideally it should not be able to move within the extra text or even after it, no matter what key or mouse button you press.  So I'm modifying the Peek methods in nsFrame and nsTextFrame to control where the caret can go.  I feel like it's getting too tailored to this use case though.  (Could we subclass nsTextFrame just for Firefox's urlbar?)

I'm wondering whether it would be possible to force the extra text to be in a frame separate from the normal text, and then turn off its editability.  I tried adding a text node for the extra text, from the front-end, and it kind of works, but you can get into a situation where sometimes the caret gets stuck inside the editable text, I'm guessing because more text nodes are accidentally created.  And that also doesn't prevent the caret from moving to the end, which would be nice.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Why did you add a new selection type?

Maybe the best approach would be to render the annotation text with a span which is positioned under the URLbar editable element, where the position of the span is updated every time the URLbar text changes.

Comment 6

[Drew Willcoxon :adw]

Could you describe in terms of code what you mean?  The urlbar "editable element" is an html:input, which can't grow and shrink with the text inside it, or show text "under" it, so I presume you're talking about something else?

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

How hard would it be to use contenteditable instead of <input>?

Comment 8

[Drew Willcoxon :adw]

That's not very feasible, but I'm looking at it.

Comment 9

[Drew Willcoxon :adw]

Yeah replacing the input with a contenteditable is not practical.  I haven't been able to get it to work and as far as I can tell we'd have to redesign a large amount of code.

Comment 10

[Marco Bonardo [:mak]]

with the new styling this is likely getting a lower priority, cause it's less prominent and we're basically now on-par with most of the other browsers (at least Edge and Chrome have a pre-selected first row).
We should likely rediscuss it, in the meanwhile I'd suggest to interrupt coding unless we have some new great ideas on how to do it.

Comment 11

[Marco Bonardo [:mak]]

This is officially on-hold until we figure the interaction with Universal Search. We are currently being consistent with all the major browsers in the market.

Comment 12

[bryan]

(In reply to Marco Bonardo [::mak] (Away 6-20 Aug) from comment #0)
> Now that we have a stable experience we could try to visually hide the
> heuristic entry and merge its information in the input field. Things should
> ideally keep working correctly since it's only a visual change. Tests will
> need some fixes.

Could we just go ahead and hide the heuristic entry completely (or have that preference in about:config or elsewhere)? For me it doesn't seem to be useful anyway (the thing that is getting auto-completed into the input field is always matching the heuristic entry).

So it's just duplicated/waste of space as indicated above. Additionally, it impacts ease of navigation to second drop-down result which is vastly awesomer result?

I guess it would be a separate issue to improve the heuristic (seemed better <FF43 or <FF48 with browser.urlbar.unifiedcomplete toggled). Does a bug for this exist? Just with my own usage (lots of history, bookmarks, visit counts, tags) the heuristic entry seems to be just matching the first thing in bookmarks/history where the text being typed matches a subdomain/domain from first chars after protocol://. Not so awesome, at all.

Just to show what I mean with Marko's example:
[porcupine_                                           ]
| porcupine.com - Visit                               | (preselected)
| Porcupine - https://porcupine.com/favorite_url.html |
| other results                                       |
we get:
[porcupine_<.com>                                     ] (preselected/autocompleted)
| Porcupine - https://porcupine.com/favorite_url.html |
| other results                                       |
or improved:
[porcupine_<.com/favorite_url.html>                   ] (preselected/autocompleted)
| other results                                       |

Comment 16

[flaezitri]

the "search with ___" / "visit" entry bothers me mostly because it introduces an unnecessary (in my case) gap between the input box and the first relevant result, but also because I find the highlighting of the redundant entry distracting.

the proposed solution would satisfy me, because it would fully address the first concern and I believe would be less visually intrusive as well. In addition, even if a user still doesn't want the hint displayed in the way proposed, including it separate from the dropdown box might make it easier to hide with userChrome.css (as things stand, it's easy to hide the dropdown entry, but then you get issues like an empty dropdown appearing when there are no other results).

alternatively, if we could just get an about:config preference to disable suggesting "search with ___" / "visit", like the already existing options to disable suggesting bookmarks, history, open tabs, and searches, that would be equally great:
browser.urlbar.suggest.bookmark
browser.urlbar.suggest.history
browser.urlbar.suggest.openpage
browser.urlbar.suggest.searches

Comment 18

[Marco Bonardo [:mak]]

This is not something that is going to happen anytime soon, we should start from an UX effort (new design) to do something like this. Plus we may be willing to provide more autofill functionality for searching that may clash with this.