Add UI prefs for new places history functionality

RESOLVED FIXED in seamonkey2.0a3

Status

RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: kairo, Assigned: kairo)

Tracking

Trunk
seamonkey2.0a3
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

10 years ago
A few preferences should be added for some new features the places history supports. I'm still undecided if we want the max number of URLs to store in addition to the days in the history panel, we probably want at least one or two prefs tweaking the location bar search algorithm as well.

Comment 1

10 years ago
String matching - apparently there is already pref browser.urlbar.matchBehavior:

0 = Search anywhere within available text, irrespective of word
boundaries.
1 = Use word boundaries first when searching, then try matching
anywhere in the text.
2 = Use only word boundaries when searching for typed text in the
Location Bar autocomplete.
3 = Match only the beginning of page URLs

But neither 2 or 3 is exactly like before. Setting 3 is close but doesn't ignore the www. prefix. Perhaps a setting 4 is needed which would be the same as 3 but also ignore the www. prefix.


Page title matching:

browser.urlbar.matchTitles (integer or boolean)
0 = don't search page titles (old behavior, URLs only)
1 = search page titles (new behavior)


Frecency algorithm:

Perhaps add a boolean pref like browser.urlbar.useFrecency - if set to false then all of the frecency stuff would be ignored, there would be no background calculations and the history items would appear as they always have in autocomplete (which seems to be straightforward LIFO).


There really needs to be a way to make the location bar work as it always has for long time users who simply don't want these new features.

Comment 2

10 years ago
(In reply to comment #1)
> Page title matching:
> 
> browser.urlbar.matchTitles (integer or boolean)
> 0 = don't search page titles (old behavior, URLs only)
> 1 = search page titles (new behavior)

This can be accomplished by setting browser.urlbar.match.url from its default "@" to an empty string, then only URLs but not titles are matched.

As for UI elements, it may be preferable to have some higher-level settings which may combine several actions in a JS function. For the given example, a text element for the browser.urlbar.match.* choices may not be intuitively clear, whereas a radio-button or drop-down list such as

[ ] Match URL only in history
[x] Match URL and titles in history
[ ] Match both in history and bookmarks

may be easier to understand.

Comment 3

10 years ago
I thought SeaMonkey was NOT going to mix bookmarks with the history, this behavior makes absolutely no sense at all. Bookmarks and history are two different things. If someone wants to access a bookmark then go through the bookmark menu or use a bookmark keyword.
(In reply to comment #3)
> I thought SeaMonkey was NOT going to mix bookmarks with the history, this
> behavior makes absolutely no sense at all. Bookmarks and history are two
> different things. If someone wants to access a bookmark then go through the
> bookmark menu or use a bookmark keyword.

IIUC, SeaMonkey was going to _allow users not to_ mix bookmark with history, not necessarily _prevent users from_ mix B with H. If some users want to autocomplete from both bookmarks & history, and there's no (or negligible) cost in terms of Sm devs' manpower (because the backend already provides the functionality), then why not? Sm's UI has always been aimed towards letting the user choose.

Comment 5

10 years ago
I'd like to emphasize that I didn't intend to make any statement on whether or not bookmarks should be included into the search, but mainly to illustrate how multiple prefs could be combined to a single item in the history pane.
(Assignee)

Comment 6

10 years ago
asmpgmr:
This bug is not about creating any prefs in the backend that don't exist yet, please file those against toolkit places, and this bug is neither about making exactly what SeaMonkey 1.1. did available.
This patch is only for adding UI for prefs that already do exist. browser.urlbar.match.* are difficult to represent in UI, btw, and unless someone tells me a solution that really works well with the awkward coupling of different things that those prefs are working with, I'll not look into that.
(Assignee)

Comment 7

10 years ago
Actually, I just saw that bug 463459 landed on trunk and will go 1.9.1 as well, so that we should be able to do a UI pref for url/url+title matching much more easily :)

Comment 8

10 years ago
Great, that would introduce "browser.urlbar.default.behavior" as an integer pref with a bitmask for the items to match, indeed much more convenient than those string-based matching prefs. Also, "browser.urlbar.matchBehavior" should be another candidate for a UI element, those two could provide the means for the not-too-advanced user to steer the basic matching behavior.

Comment 9

10 years ago
(In reply to comment #1)
> String matching - apparently there is already pref
> browser.urlbar.matchBehavior:
> 
...
> 3 = Match only the beginning of page URLs
> 
> But neither 2 or 3 is exactly like before. Setting 3 is close but doesn't
> ignore the www. prefix. Perhaps a setting 4 is needed which would be the same
> as 3 but also ignore the www. prefix.

Yes, this is indeed needed. See bug 461483.

Updated

10 years ago
Depends on: 461483
(Assignee)

Updated

10 years ago
Depends on: 471886
(Assignee)

Comment 10

10 years ago
Created attachment 355217 [details] [diff] [review]
v1: add a few prefs to history and location bar panels

Here's the set of places prefs I think is reasonable to add to the panels:

On the history panel, we make clear that the pref we had is maximum days of retention, and we add the minimum time as well as the max number of sites to keep.

On the location bar panel, we add the bit of default.behavior that restricts to matching the URL only (code for reading/setting the bit taken from keyboard nav panel) and the matchBehavior pref that defines if we match anywhere (even in the middle), on word boundaries or the beginning of the URL/title only - this is done as a menulist to not use too much space in this already pretty filled panel.
Assignee: nobody → kairo
Status: NEW → ASSIGNED
Attachment #355217 - Flags: superreview?(neil)
Attachment #355217 - Flags: review?(stefanh)

Comment 11

10 years ago
Comment on attachment 355217 [details] [diff] [review]
v1: add a few prefs to history and location bar panels

>       (!autoFillPref.value && !showPopupPref.value) || !autoCompletePref.value;
Nit: should reuse this calculation somehow

>       <preference id="browser.urlbar.autocomplete.enabled"
>                   name="browser.urlbar.autocomplete.enabled"
>                   type="bool"
This pref isn't supported by toolkit - see bug 471903. In case that doesn't get fixed, we could bit-twiddle the default behaviour instead...

>       <checkbox id="autoFill"
>                 class="indent"
>                 label="&autoCompleteAutoFill.label;"
>                 accesskey="&autoCompleteAutoFill.accesskey;"
>                 preference="browser.urlbar.autoFill"/>
>       <checkbox id="showPopup"
It looks odd to me that these checkboxes follow the controls they disable...

>+<!ENTITY autoCompleteMatchOnlyURLs.label       "Only match URLs, not website titles">
Maybe we should invert this pref: "Match page titles as well as URLs" ?

>+<!ENTITY autoCompleteMatchAnywhere             "Anywhere">
>+<!ENTITY autoCompleteMatchWordsFirst           "On word boundaries before trying anywhere">
"Anywhere but preferring word boundaries"
>+<!ENTITY autoCompleteMatchWords                "Only on word boundaries">
>+<!ENTITY autoCompleteMatchStart                "At the beginning of the url or title">
"Only at the beginning of the url or title"
Attachment #355217 - Flags: superreview?(neil) → superreview+

Comment 12

10 years ago
Comment on attachment 355217 [details] [diff] [review]
v1: add a few prefs to history and location bar panels

FYI, I'll look at this before the weekend.

Comment 13

10 years ago
(In reply to comment #11)
> >+<!ENTITY autoCompleteMatchOnlyURLs.label       "Only match URLs, not website titles">
> Maybe we should invert this pref: "Match page titles as well as URLs" ?

Maybe it's unclear what happens when you uncheck the pref then?

Updated

10 years ago
Attachment #355217 - Flags: review?(stefanh) → review+

Comment 14

10 years ago
Comment on attachment 355217 [details] [diff] [review]
v1: add a few prefs to history and location bar panels

>       (!autoFillPref.value && !showPopupPref.value) || !autoCompletePref.value;
As Neil points out, you should re-use this. One way is to store this in a var before all the if:s.

Some general thoughts: I think it's a bit unclear having "Match" before the drop-down when we're using the same word in the checkboxes above. We have 2 different matches here, first what we actually use for kind of source (url, title) and then how we match the actual string. I don't this distinction is clear enough in the ui. But I don't have any better solution right now, so I guess it's ok (Neils suggestions makes it a bit more clear, though). I might file a bug if I get any ideas ;-)

Re the History panel:

+<!ENTITY  expireDaysMin1.label              "Remember visited pages for at least">
"Always remember visited pages for at least"

Actually, initially I was a bit confused when I looked at the panel. Maybe those prefs are an overkill? If they aren't, maybe we should make it even clearer in the ui how those prefs depend on each other? Follow-up material, though.

r=me with the history panel string fixed and Neils comments addressed.
(Assignee)

Updated

10 years ago
Blocks: 472840
(Assignee)

Comment 15

10 years ago
Pushed as http://hg.mozilla.org/comm-central/rev/f3eda128cbd3
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Updated

10 years ago
Target Milestone: --- → seamonkey2.0a3
(Assignee)

Updated

10 years ago
Blocks: 473734
(Assignee)

Updated

10 years ago
Blocks: 479068

Updated

10 years ago
No longer blocks: 479068

Updated

9 years ago
Duplicate of this bug: 468987
You need to log in before you can comment on or make changes to this bug.