Bug 1398416 Comment 13 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Drew Willcoxon :adw from comment #12)
> I think we should rely 100% on historical searches bubbling up through the usual frecency mechanism from Places history, and we shouldn't rely on form history at all. Therefore I propose that we remove the `maxHistoricalSearchSuggestions` pref and hardcode that value to zero.

There are a couple cases where form history may still be useful, and I can't think of cases where it would be bad, unless it's to save on I/O? I'd like to hear more about the concerns.

The cases coming to my mind are:
1. Search history is shared across all the search fields, history is not. Of course long term we aim at a single SAP, so this is probably ok.
2. If history is disabled or cleared on shutdown, we could still use search history, and it would be useful to the user. For this maybe  it could be worth to still store search history from the urlbar, and enable it only when history is disabled or cleared on shutdown?
3. if the search url changes (and they do but I don't know how often), history won't be reverse-parsed.

I fear this requires a broader discussion also involving PM, because I can't tell how bad 2. and 3. may be.
My off-hand suggestion would be to store search history at least, so we can make use of it if/when necessary, but I'm not sold on a solution yet.

> However, comment 0 here also talks about the ability to easily edit your search terms. So I suggest we leave this open but make it specifically about that, and not about restyling searches or historical searches.

What do we put in the input field when a reverse-parsed result is selected? We should probably only reverse parse engines with a token alias, and put in the input field "@token search terms" (unless it's the default engine, then it's only "search terms") and it looks pretty easy to edit it at that point.
(In reply to Drew Willcoxon :adw from comment #12)
> I think we should rely 100% on historical searches bubbling up through the usual frecency mechanism from Places history, and we shouldn't rely on form history at all. Therefore I propose that we remove the `maxHistoricalSearchSuggestions` pref and hardcode that value to zero.

There are a couple cases where form history may still be useful, and I can't think of cases where it would be bad, unless it's to save on I/O? I'd like to hear more about the concerns.

The cases coming to my mind are:
1. Search history is shared across all the search fields, history is not. Of course long term we aim at a single SAP, so this is probably ok.
2. If history is disabled or cleared on shutdown, we could still use search history, and it would be useful to the user. For this maybe  it could be worth to still store search history from the urlbar, and enable it only when history is disabled or cleared on shutdown?
3. if the search url changes (and they do but I don't know how often), history won't be reverse-parsed.

I fear this requires a broader discussion also involving PM, because I can't tell how bad 2. and 3. may be.
My off-hand suggestion would be to store search history at least, so we can make use of it if/when necessary, but I'm not sold on a solution yet.

> However, comment 0 here also talks about the ability to easily edit your search terms. So I suggest we leave this open but make it specifically about that, and not about restyling searches or historical searches.

What do we put in the input field when a reverse-parsed result is selected? We should probably only reverse parse engines with a token alias, and put in the input field "@token search terms" (unless it's the default engine, then it's only "search terms") and it looks pretty easy to edit at that point.

Back to Bug 1398416 Comment 13