Bugzilla

(In reply to megancutrofello from comment #18)
> and the lack of use is due to lack of advertisement more than anything.

That's a red herring. First of all the idea is not to change bookmark keywords because they are not used enough, but because:
1. we have duplicated code and functionality doing almost the same thing, that is a cost to maintain and breaks more easily
2. bookmark keywords are hard to find AFTER they were added, indeed we got tens of reports from users who forgot they had created them, and that's because they are defined as a property of a bookmark, thus you must know where the bookmark is and edit it to find whether it has a keyword. We would like the feature to be easier to use for everyone.
3. There's absolutely no reason for which a magic word creating a dynamic url when you search should be the property of a bookmark. It was made just because at the time it looked cheap, but it was not in reality, as we discovered later.

So, we think it's a powerful feature that should have its own codebase in search rather than being buried in bookmarks just because at the time it looked simple to do.

> Also, I'm curious, what is the bulk-managing like for search engines? Even in the non-javascript case, I'm managing literally over a thousand keywords in an external HTML file that I re-import.

Unfortunately your use case of having hundreds or thousands keywords, even in subfolders is very uncommon, that means spending resources on supporting it would benefit very few users (among which you), rather than being a tool for everyone. And I don't think supporting both is easy, if it should be easily discoverable and usable by everyone, and more widespread, hierarchies are the wrong answer, due to the complecity they add. For that case it is more likely something along the path of add-ons should be done, then it could satisfy perfectly that additional needs from a small set of users, that's what add-ons are for, maximum adaptation to single persons use cases.

I am wondering if you played a bit with the Omnibox WebExtension API, there you can define a magic keyword and build urls on the fly, for example you could register "magic" and then type "magic <modifier> <search term>" and build urls and suggestions out of it. We're open to provide enhancements to that API if it needs more flexibility or support in the urlbar.

(In reply to megancutrofello from comment #21)
> The biggest issue is javascript bookmarklets

I think this is an issue that the team should investigate, there may not be a strong reason to not support custom javascript search urls (provided one can't set them as default engine), even if it's behind a pref in case we consider them "scary".

(In reply to megancutrofello from comment #18)
> and the lack of use is due to lack of advertisement more than anything.

That's a red herring. First of all the idea is not to change bookmark keywords because they are not used enough, but because:
1. we have duplicated code and functionality doing almost the same thing, that is a cost to maintain and breaks more easily
2. bookmark keywords are hard to find AFTER they were added, indeed we got tens of reports from users who forgot they had created them, and that's because they are defined as a property of a bookmark, thus you must know where the bookmark is and edit it to find whether it has a keyword. We would like the feature to be easier to use for everyone.
3. There's absolutely no reason for which a magic word creating a dynamic url when you search should be the property of a bookmark. It was made just because at the time it looked cheap, but it was not in reality, as we discovered later.

So, we think it's a powerful feature that should have its own codebase in search rather than being buried in bookmarks just because at the time it looked simple to do.

> Also, I'm curious, what is the bulk-managing like for search engines? Even in the non-javascript case, I'm managing literally over a thousand keywords in an external HTML file that I re-import.

Unfortunately your use case of having hundreds or thousands keywords, even in subfolders, is very uncommon, that means spending resources on supporting it would benefit very few users (among which you), rather than being a tool for everyone. And I don't think supporting both is easy, if it should be easily discoverable and usable by everyone, and more widespread, hierarchies are the wrong answer, due to the complecity they add. For that case it is more likely something along the path of add-ons should be done, then it could satisfy perfectly that additional needs from a small set of users, that's what add-ons are for, maximum adaptation to single persons use cases.

I am wondering if you played a bit with the Omnibox WebExtension API, there you can define a magic keyword and build urls on the fly, for example you could register "magic" and then type "magic <modifier> <search term>" and build urls and suggestions out of it. We're open to provide enhancements to that API if it needs more flexibility or support in the urlbar.

(In reply to megancutrofello from comment #21)
> The biggest issue is javascript bookmarklets

I think this is an issue that the team should investigate, there may not be a strong reason to not support custom javascript search urls (provided one can't set them as default engine), even if it's behind a pref in case we consider them "scary".

(In reply to megancutrofello from comment #18)
> and the lack of use is due to lack of advertisement more than anything.

That's a red herring. First of all the idea is not to change bookmark keywords because they are not used enough, but because:
1. we have duplicated code and functionality doing almost the same thing, that is a cost to maintain and breaks more easily
2. bookmark keywords are hard to find AFTER they were added, indeed we got tens of reports from users who forgot they had created them, and that's because they are defined as a property of a bookmark, thus you must know where the bookmark is and edit it to find whether it has a keyword. We would like the feature to be easier to use for everyone.
3. There's absolutely no reason for which a magic word creating a dynamic url when you search should be the property of a bookmark. It was made just because at the time it looked cheap, but it was not in reality, as we discovered later.

So, we think it's a powerful feature that should have its own codebase in search rather than being buried in bookmarks just because at the time it looked simple to do.

> Also, I'm curious, what is the bulk-managing like for search engines? Even in the non-javascript case, I'm managing literally over a thousand keywords in an external HTML file that I re-import.

Unfortunately your use case of having hundreds or thousands keywords, even in subfolders, is very uncommon, that means spending resources on supporting it would benefit very few users (among which you), rather than being a tool for everyone. And I don't think supporting both is easy, if it should be easily discoverable and usable by everyone, and more widespread, hierarchies are the wrong answer, due to the complexity they add. For that case it is more likely something along the path of add-ons should be done, then it could satisfy perfectly that additional needs from a small set of users, that's what add-ons are for, maximum adaptation to single persons use cases.

I am wondering if you played a bit with the Omnibox WebExtension API, there you can define a magic keyword and build urls on the fly, for example you could register "magic" and then type "magic <modifier> <search term>" and build urls and suggestions out of it. We're open to provide enhancements to that API if it needs more flexibility or support in the urlbar.

(In reply to megancutrofello from comment #21)
> The biggest issue is javascript bookmarklets

I think this is an issue that the team should investigate, there may not be a strong reason to not support custom javascript search urls (provided one can't set them as default engine), even if it's behind a pref in case we consider them "scary".