Closed Bug 468326 Opened 12 years ago Closed 12 years ago
Add UI prefs for new places history functionality
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.
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.
(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.
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.
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.
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.
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 :)
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.
(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.
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.
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 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.
(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?
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.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.