618619 - Add support for more browser.urlbar.default.behavior values (History and Bookmarks) to Location Bar Autocomplete

Status: RESOLVED DUPLICATE of bug 1098350

(SeaMonkey :: Preferences, defect)

Description

[Jens Hatlak (:InvisibleSmiley)]

Since we have Places-based bookmarks now, we should finally allow to select more of the common browser.urlbar.default.behavior [1] pref values through the Preferences UI. Firefox (Minefield) has under Options/Privacy:
"When using the location bar, suggest: [drop-down with below labels]"
* History and Bookmarks (0)
* History (1)
* Bookmarks (2) 
* Nothing (browser.urlbar.autocomplete.enabled=false; browser.urlbar.default.behavior unchanged)

Note: 0 and 2 include 4 (Tags).

We should really have that, so suggesting to block final on this.

[1]: http://kb.mozillazine.org/Browser.urlbar.default.behavior

Comment 1

[Jens Hatlak (:InvisibleSmiley)]

We might also want to change our default to 0 (but in case this is controversial, maybe better in a new bug).

Comment 2

[Robert Kaiser]

Hmm, I thought I would have filed a bug for this. All in all, it shouldn't be too difficult to do, but we need to make sure we test all those.

Comment 3

[Robert Kaiser]

String additions may not be able to block final, we don't know when we really want to freeze strings.

Comment 4

[Jens Hatlak (:InvisibleSmiley)]

Attachment: the real deal

This is what I came up with after I decided that anything similar to Firefox's UI (or our own, old one, for that matter) is too limited for my taste. Only the full set of possible combinations allows me to not think about this as a wasted opportunity (because anything shorter than that means a possible discrepancy between pref value and UI, with all the implications). That's why I won't assign (commit) to this unless I get an r+ or at least general f+.

That said, this of course needs a Help bug, but given the size of what I propose here (and already coded up the last couple of hours) I recommend moving that to a follow-up for the sake of discussion/clarity.

Comment 5

[Robert Kaiser]

Completely from a UI POV, I don't yet like "Suggest as you type" as I'm not sure if it's clear enough for users (though "suggest" instead of "autocomplete" is an improvement).
Also, I don't see any real reason for your change to "match" that doesn't really change what a user can select, but makes it harder to understand.

Comment 6

[Jens Hatlak (:InvisibleSmiley)]

Attachment: screen shot

(In reply to comment #5)
> Completely from a UI POV, I don't yet like "Suggest as you type" as I'm not
> sure if it's clear enough for users (though "suggest" instead of "autocomplete"
> is an improvement).

We can surely talk about that part.

> Also, I don't see any real reason for your change to "match" that doesn't
> really change what a user can select, but makes it harder to understand.

I guess I should have told you that the reason for that change was brevity. See the attached screen shot.

Basically I needed to save space vertically because aligning the checkboxes horizontally is a UI design no-go (cf. my comment on bug 640109; the vertical space between the checkboxes could be reduced, though, which matches Philip's suggestion on bug 608103). So I came up with the idea of putting all the "match" stuff on one row, which lead to a horizontal space problem, which I then solved by cutting down string lengths.

Comment 7

[Robert Kaiser]

Well, with this design, we probably will run into some issues with localizations anyhow, as you can't count on localized descriptions on those checkboxes not needing wrapping and your selection boxes fitting horizontally in the space in all all locales. IIRC, we are don't use "URL" anywhere else in normal prefs UI but only "location".

Comment 8

[Jens Hatlak (:InvisibleSmiley)]

Attachment: screen shot v2

(In reply to comment #7)
> Well, with this design, we probably will run into some issues with
> localizations anyhow, as you can't count on localized descriptions on those
> checkboxes not needing wrapping and your selection boxes fitting horizontally
> in the space in all all locales.

I already thought about that, too, but left it aside for starters so I could present something. On second thought it looks like we can easily put the four "type from" checkboxes (that are aligned vertically in the first screen shot) in a 2x2 grid (with a spacer in between two horizontal ones to make sure each checkbox is always clearly associated with its label with any locale). That frees up a whole line of vertical space which allows to distribute the "Match" stuff over two lines.

> IIRC, we are don't use "URL" anywhere else in normal prefs UI but only
> "location".

That I can change back easily. It even fits in the design I originally proposed, though I'm not saying this justifies sticking to the original design. Well, pictures often tell more than words, to here we go.

Comment 9

[Jens Hatlak (:InvisibleSmiley)]

Attachment: patch v2

This time I even remembered the Help button accesskey clash.

Comment 10

[[e-mail]]

Comment on attachment 518422 [details]
screen shot v2

So, the preferences don't actually do what this screen shot suggests. A zero preference means that any page in Places can be matched on either title or URL. Adding bits restricts the matches as follows:
HISTORY: Page must have been visited
BOOKMARK: Page must have been bookmarked
TAG: Bookmark must have been tagged with the search string (implies BOOKMARK)
TITLE: Title must match the search string
URL: URL must match the search string
TYPED: URL must have been marked as typed (implies HISTORY)
Not sure what the other two bits do yet.

Comment 11

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #10)
> So, the preferences don't actually do what this screen shot suggests.

What does it suggest, IYO?

> A zero
> preference means that any page in Places can be matched on either title or URL.
> Adding bits restricts the matches as follows:
> HISTORY: Page must have been visited
> BOOKMARK: Page must have been bookmarked
> TAG: Bookmark must have been tagged with the search string (implies BOOKMARK)
> TITLE: Title must match the search string
> URL: URL must match the search string
> TYPED: URL must have been marked as typed (implies HISTORY)
> Not sure what the other two bits do yet.

Maybe I made small mistakes, like the URL/HISTORY dependencies, but otherwise I think I implemented all that (e.g. pref=0 -> History and Bookmarks checked). Granted, you cannot see that from the screen shot alone (you'll have to check the patch for that), but I tried hard to match the information provided on the page linked in comment 0 in all situations. And no, TAG does not imply BOOKMARK (but BOOKMARK implies tag), though of course you need to have a bookmark to have a tag.

Comment 12

[Jens Hatlak (:InvisibleSmiley)]

"(but BOOKMARK implies TAG)"

Comment 13

[[e-mail]]

(In reply to comment #11)
> I think I implemented all that (e.g. pref=0 -> History and Bookmarks checked).
> Granted, you cannot see that from the screen shot alone
The problem is that the preference has a subtractive effect, while you are trying to display an additive effect, which isn't right even when you flip the sense of the checkboxes. (In fact I now notice the linked page refers to a comment in firefox.js that points out that each filter restricts more.)

As a further example, the choice for whether to match URL or title is 0) either can match 8/16) match one as appropriate 24) both must match.

When I said TAG implies BOOKMARK, this is because only bookmarks can be tagged, so if you match a tag, then the result must be a bookmark. I don't know how easy it is to express that in the UI, perhaps using menulists:

Match pages from history: [Page must be visited[V]]
                           Not required
                           Page must be visited
                           Page must be typed

Match pages from bookmarks: [Not required           [V]]
                             Not required
                             Page must be bookmarked
                             Bookmark tag must match

Match: [Either page URL or title[V]]
        Either page URL or title
        Page title only
        Page URL only
        Both page URL and title

Or maybe we can stick with checkboxes, disabling them appropriately:

+-- Filter pages according to the following criteria --+
| [X] Page must be visited {disabled if typed ticked}  |
| [ ] Page must be bookmarked {disabled if tag ticked} |
| [ ] Bookmark tag must match                          |
| [ ] Page title must match                            |
| [ ] Page URL must match                              |
| [ ] Page must be typed                               |
+------------------------------------------------------+

Comment 14

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #13)
> The problem is that the preference has a subtractive effect, while you are
> trying to display an additive effect

Well explained, thanks for pointing this out! I guess I should have checked more thoroughly.

Free to take.

Comment 15

[Justin Wood (:Callek)]

While wanted, this is just UI for a feature addition we got mostly for free, no worry if we don't adjust this. So since no owner I'm going to drop blocking on this.

Still wanted though.