Open Bug 1653261 Opened 6 months ago Updated 5 days ago

[meta] Migrate keyword bookmarks into about:preferences managed Search Engines

Categories

(Firefox :: Search, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: daleharvey, Unassigned)

References

(Depends on 4 open bugs, Blocks 5 open bugs)

Details

(Keywords: meta)

No description provided.
Blocks: search-alias
Depends on: 1650894
Depends on: 1106626
Depends on: 1650892
Depends on: 1653262
Severity: -- → N/A
Priority: -- → P3
Blocks: 1659811
Depends on: 1661654

Dear Firefox devs,

One of the hackish usage of keyword bookmark is to execute some javascript to redirect the page. Here an example to redirect from any subscribtion-based scientific journal page to that same page accessed through the library proxy "EZproxy".

URL: javascript:void(location.href=%22https://ezproxy.my-university.edu/login?url=%22+location.href)
keyword: ez (or whatever...)

Will this hack still work with the new design? If not, is there an alternative?

Best,
Pierre

(In reply to pierre.haessig from comment #1)

URL: javascript:void(location.href=%22https://ezproxy.my-university.edu/login?url=%22+location.href)
keyword: ez (or whatever...)

Will this hack still work with the new design? If not, is there an alternative?

You will still be able to use bookmarklets to achieve what you want, but you won't be able to assign a direct keyword. Possible alternatives are:

  • Show the bookmarks toolbar and have the bookmarklet on there.
  • Pin the bookmarklet as a top site on the new tab page, it'll then be accessible if you do ctrl-L (or cmd-L on Mac).
  • Tag the bookmarklet or give it a title so that you can easily access it via typing.

These methods all work in the current version of Firefox.

Thanks a lot for the feedback Mark.

I suppose that the "top site" solution is not compatible with a bookmarklet using location.href. However, the bookmark toolbar or the carefully chosen title or tag should work. Only, the latter may be a bit less reliable than the keyword since it would rely on the sorting algorithm of the address bar which can change over time.

(In reply to pierre.haessig from comment #3)

I suppose that the "top site" solution is not compatible with a bookmarklet using location.href.

This would be interesting to know if you're willing to help testing it, if you are on a page and click on the urlbar, Top Sites are shown automatically, and picking the bookmark should ideally work. But it's currently untested.

This would be interesting to know if you're willing to help testing it, if you are on a page and click on the urlbar, Top Sites are shown automatically, and picking the bookmark should ideally work. But it's currently untested.

Good idea. I did the following. On the newtab page, open the "…" menu of the Top sites section and select "+ Add a popular website" (NB: I'm translating back from the French translation).

In the "New popular site" dialog that pops up, I put in the URL field:

javascript:void(location.href=%22https://ezproxy.my-university.edu/login?url=%22+location.href)

When pressing the "Add" button, it fails with a red pop up around the URL field "Valid address required". So it seems that for this solution to work, the URL filter needs to be relaxed?

Summary: [meta] Migrate keyword bookmarks into about:prefences managed Search Engines → [meta] Migrate keyword bookmarks into about:preferences managed Search Engines

Firefox Sync supports keyword bookmarks. Will support for search engines be added to Sync? If not, how can I keep them synchronised across my devices?

(In reply to Aidan Corey from comment #6)

Firefox Sync supports keyword bookmarks. Will support for search engines be added to Sync? If not, how can I keep them synchronised across my devices?

We are aware of this issue and currently considering it. Note: sync for search engines is bug 444284, so that is main one to follow, no need to comment separately on it.

Bookmark keywords are a powerful feature used by advanced users. From my understanding this feature is unique to Firefox. I think unifying search engines and bookmark search in principal is a good idea, but not at the expense of breaking too many things.

I think there are two important pieces missing here, that should be addressed:

  • Sync support
  • Support for non-http(s) search engines especially javascript:

Consider for example this blogpost written in the last few days: https://river.me/blog/url-bar-is-a-cli/. One example uses javascript: and the bookmarks folders for organizations.

I think it's also interesting to see that Firefox for Android (Fenix) is soon going to have bookmark keyword support: https://github.com/mozilla-mobile/fenix/pull/14957

I know many average users consider telemetry to be biased against advanced users, but it would still be nice to have telemetry numbers for some of the stuff here. PLACES_KEYWORDS_COUNT seems to indicate about 98% of beta users have no keywords, but 72% of nightly users have 2! I think that nicely illustrates the point of it being a feature used by advanced users. I would like to see some stats for the javascript: use as well.

(I know this is more a mailinglist thing, but I hate using dev-firefox, sorry)

Depends on: 1666600

I have about 25 of these set up, with about 10 that I use daily. So, instead of

[Ctrl]+[L], type "xkcd usecase"

I now have to

[Ctrl]+[L], type usecase and then mash [Up] and [left/right] often enough to find one of 25 items.

Will keywords really not be available any more at all? Any way of fast-choosing the "search engine"? It should also be noted that some of these, I would never consider "search engines" to begin with. Another thing with search engines is, that they seem to be only distinguished by their favicon. But quite a few of mine are actually the same search engine but with some tweaked keywords prefilled - I can't visually distinguish them by favicon. With keywords that was not a problem.

I collected a few of these in this github issue of firefox on android, where keywords are already missing.

https://github.com/mozilla-mobile/fenix/issues/12099#issuecomment-684873431

Search engines already have the ability to set an alias and there isnt any plans to change that, the change proposed here is that xkcd is shown and managed in about:preferences#search instead of in bookmarks

What we do with keywords that are not search engines is an open (and possibly unrelated) question

So, I can keep using the location bar (important for the Ctrl+L shortcut) and it does work with a keyword-like prefix (so I don't have to fumble with 20 icons before finding the "right" search)? Is there a way I can test-drive this right now? I was not able to find documentation on how to add custom "search engines", only this document which does not explain completely custom searches.

https://support.mozilla.org/en-US/kb/add-or-remove-search-engine-firefox

(In reply to Claudius from comment #12)

So, I can keep using the location bar (important for the Ctrl+L shortcut) and it does work with a keyword-like prefix (so I don't have to fumble with 20 icons before finding the "right" search)?

Yes.

Is there a way I can test-drive this right now?

You can set a keyword on any search engine in preferences. If you add an engine (e.g. for this site via the three-dot menu on the address bar and "add search engine"), they will behave the same way as will a custom engine.

I was not able to find documentation on how to add custom "search engines", only this document which does not explain completely custom searches.

That's because this feature/change is not ready yet and has not even been enabled on nightly builds at this time.

(In reply to Tom Schuster [:evilpie] from comment #8)

I know many average users consider telemetry to be biased against advanced users, but it would still be nice to have telemetry numbers for some of the stuff here. PLACES_KEYWORDS_COUNT seems to indicate about 98% of beta users have no keywords, but 72% of nightly users have 2! I think that nicely illustrates the point of it being a feature used by advanced users. I would like to see some stats for the javascript: use as well.

Nightly stats are not reliable because since 2016 there's been two keywords defined by default on new nightly profiles: https://searchfox.org/mozilla-central/rev/1a973762afcbc5066f73f1508b0c846872fe3952/browser/locales/generic/profile/bookmarks.html.in#42-43

Depends on: 1669756

I am using FF on Linux and with 81(.0.2) on Linux:

  1. I looks like keyword bookmarks aka. quick searches stopped working ... I have many of these with %S and %s replacements and that's 99.99% of my basic usage of FF. Entering the keyword alone goes to the bookmark, but keyword + other string, goes to the default search engine, which is not correct
  2. there is no possibility to create custom search engines to the same effect that I could find.

What would be the workaround until this ticket is fixed and released?
Thanks!

(In reply to Philippe Ombredanne from comment #14)

I am using FF on Linux and with 81(.0.2) on Linux:

  1. I looks like keyword bookmarks aka. quick searches stopped working ... I have many of these with %S and %s replacements and that's 99.99% of my basic usage of FF. Entering the keyword alone goes to the bookmark, but keyword + other string, goes to the default search engine, which is not correct

We have not changed anything with respect to this in 81.x.

What would be the workaround until this ticket is fixed and released?

Please file a separate bug and include information from the browser console.

Duplicate of this bug: 1346799
Blocks: 1635831
Blocks: 1678629
Blocks: 1662194

Hey, I'm the author of the post that was linked above (https://river.me/blog/url-bar-is-a-cli/), and someone just linked me this thread. Bookmark keywords (especially with the ability to execute javascript) are pretty much the single most important part of Firefox as a browser, and the lack of use is due to lack of advertisement more than anything. When I posted that article to reddit people immediately came up with tons of interesting ways to use this functionality and were very excited to learn about it. It revolutionizes workflow.

  • Show the bookmarks toolbar and have the bookmarklet on there.

No, this requires clicking.

  • Pin the bookmarklet as a top site on the new tab page, it'll then be accessible if you do ctrl-L (or cmd-L on Mac).

No, this requires tons of up/down arrow. I have like 30 of these things.

  • Tag the bookmarklet or give it a title so that you can easily access it via typing.

Bookmarklets can take arguments when paired with a keyword (e.g. gp lol Faker to search lol.gamepedia.com for Faker); as far as I can tell it doesn't work when you autocomplete with a tag (I just tried). Also, there's significant noticeable UI lag in this method. Also, even if it did work, suddenly my URL bar is filled with tons of JS spam and the UX of editing a search query is pretty poor.

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.

Please, read my article about how beautiful this tool is. It's not advertised anywhere the amazing capability of bookmark keywords, and that's the reason that it's power-user-only, but this is not a reason to remove it from the browser, instead advertise how incredible you can make your browsing experience!!! I literally don't know how I can function as a user if you get rid of this functionality.

(In reply to Dale Harvey (:daleharvey) from comment #11)

What we do with keywords that are not search engines is an open (and possibly unrelated) question

Is this being discussed somewhere?

Since I'm not really sure the best place to discuss this, and I feel very strongly about this / will be extremely negatively impacted by this change, I wrote another post on my blog about this change. I tried to address my current use cases for keywords, and what search engines would need to support in order to fully replace keywords (though I don't think it's possible for search engines to actually replicate what keywords can do).

The biggest issue is javascript bookmarklets, so I also gave some use cases of that. Bookmarklets that take arguments are not able to be replicated with tags, or menu buttons, or pinned top sites as suggested earlier in this thread (and all of these are really poor UX when you have a lot of bookmarklets).

Beyond that, I'll let the post stand on its own: https://river.me/blog/firefox-keep-bookmark-keywords/

If there's a more appropriate place to discuss this, let me know and I'm happy to move there!

(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".

I can see the sense in some of the extended functionality @megancutrofello outlines being managed in an extension, if the APIs support such. Accessing through an additional prepended keyword would be quite bearable. I'm curious about how this might work with Sync though.

Am I right in thinking that the storage-medium for such an extension would be preferences (and thus be sync-able)?

Personally I tend not to sync prefs because the option is monolithic and many prefs are undesirable to sync between multiple different devices.

Or is there an existing facility for extensions to include their own user-settings in Sync?

extensions can implement their own syncing mechanism, or use storage.sync that is automatically synced with the Firefox Account.

What is intended to happen to bookmarks whose location does not contain =%s that I have assigned a keyword? I use a few of those several times a day for speed of navigation, and recommend them on forums to people who find the autofill feature inadequate for their needs. Will they still work even though they are not intended to take a query parameter?

Prompted by the suggestion of using the omnibox WebExtension API, I was able to find an existing addon called Custom Search Engine that sort of replicates the native bookmark keywords functionality that is being removed. However, as was pointed out in the comments above, this does require an additional, non-user-configurable[1] initial keyword (ms in the case of this addon), so if you had bookmark keywords like “r <subreddit>” or “wik <article>” you can use this extension to set up “ms r <subreddit>” or “ms wik <article>” to do the same.

However, I don’t think there is currently a way to install this on Firefox on Android, where keyword functionality has already been removed for months without a viable replacement. The current stable releases only allow a subset of addons handpicked by Mozilla.

(In reply to Mark Banner (:standard8) from comment #13)

(In reply to Claudius from comment #12)

So, I can keep using the location bar (important for the Ctrl+L shortcut) and it does work with a keyword-like prefix (so I don't have to fumble with 20 icons before finding the "right" search)?

Yes
...

I was not able to find documentation on how to add custom "search engines", only this document which does not explain completely custom searches.

That's because this feature/change is not ready yet and has not even been enabled on nightly builds at this time.

I am eagerly waiting for the replacement for this feature to be implemented for Firefox on Android. Just to add my personal experience: I also have about 10–20 bookmark keywords set up, which is too many to display as search icons (especially considering some keywords are used much less frequently), but easy to access by typing the short keywords. Ever since this feature was removed from Firefox Android, I have switched to an older version of Fennec F-Droid (v68) and disabled updates in order to keep using keywords. Obviously that’s not best practice for security, but I personally use keywords often enough every day to make that a worthwhile tradeoff for now.

1: The keyword can be set to whatever by the addon developer in the manifest.json, but there is no straightforward way for end users to change that; this is a requirement/feature of the omnibox API

(In reply to jscher2000 from comment #26)

What is intended to happen to bookmarks whose location does not contain =%s that I have assigned a keyword?

It is still under discussion, but ideally a good autofill and ranking algo should remove any need for them. Their main use case, as far as we can tell, is to cover url autofill missings.

(In reply to szupie from comment #27)

However, I don’t think there is currently a way to install this on Firefox on Android, where keyword functionality has already been removed for months without a viable replacement. The current stable releases only allow a subset of addons handpicked by Mozilla.

APIs can be implemented on Android, but with so few resources, someone from the community may have to volunteer for that. This bug is only about desktop.

(In reply to Marco Bonardo [:mak] from comment #22)

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.

Would you be willing to consider a preference to disable the requirement of the additional keyword prior to the omnibox api suggestions? That keyword has so far been the thing stopping me from wanting to use it for any purpose, and was actually want drove me to use bookmark keywords in the first place instead of any extension. With bookmark keywords gone, there's not really any other avenue for the seamless user experience that pre-quantum had, but such a preference would indeed allow this API to provide it.

With the extra keyword requirement, though, the ux is pretty poor compared to what keyword+bookmarklets currently give.

(In reply to Marco Bonardo [:mak] from comment #28)

(In reply to jscher2000 from comment #26)

What is intended to happen to bookmarks whose location does not contain =%s that I have assigned a keyword?

It is still under discussion, but ideally a good autofill and ranking algo should remove any need for them. Their main use case, as far as we can tell, is to cover url autofill missings.

What do you mean by this? For example I use lolcssme as a keyword for https://lol.gamepedia.com/Special:MyPage/common.css - this couldn't possibly autofill here.

(In reply to megancutrofello from comment #29)

Would you be willing to consider a preference to disable the requirement of the additional keyword prior to the omnibox api suggestions?

Not for now, that magic keyword exists to avoid malicious add-ons from taking control of the urlbar. While that may look like an advanced feature, we really don't want to take that risk considered how search engines and the homepage were abused in the past.

What do you mean by this? For example I use lolcssme as a keyword for https://lol.gamepedia.com/Special:MyPage/common.css - this couldn't possibly autofill here.

yes, that's not the case we're aiming at, but if you just type "lol" and in the past you usually went to that page, it should be autofilled, and it's even shorter than your special keyword.

(In reply to Marco Bonardo [:mak] from comment #30)

(In reply to megancutrofello from comment #29)

Would you be willing to consider a preference to disable the requirement of the additional keyword prior to the omnibox api suggestions?

Not for now, that magic keyword exists to avoid malicious add-ons from taking control of the urlbar. While that may look like an advanced feature, we really don't want to take that risk considered how search engines and the homepage were abused in the past.

What if it only applied to developer/local addons? This way there's still SOME recourse for maintaining true bookmark keyword functionality, and I can code my own tool, which is somewhat similar to writing bookmarklets.

What do you mean by this? For example I use lolcssme as a keyword for https://lol.gamepedia.com/Special:MyPage/common.css - this couldn't possibly autofill here.

yes, that's not the case we're aiming at, but if you just type "lol" and in the past you usually went to that page, it should be autofilled, and it's even shorter than your special keyword.

I definitely don't want lol autocompleting to this page. Here's how lol autocomplete currently looks: https://puu.sh/H4MnA.png Also, I have at least 40 bookmarks with keywords with lol in them, maybe half of them are totally static URLs, half of them are single-replacement "search engine" bookmarks. So if just "lol" is what's autocompleting, that's not helpful at all.

For an example that completely could not autofill period, then bsfp ("black survival front page") goes to https://blacksurvival.gamepedia.com/Black_Survival_Wiki. Keywords definitely don't need anything in common with the url they point to.

(In reply to Marco Bonardo [:mak] from comment #28)

[...] This bug is only about desktop.

Please tell that to @Mugurell and @kbrosnan on GitHub, who closed and even LOCKED that issue pointing at this one here: https://github.com/mozilla-mobile/fenix/issues/12099#issuecomment-704143064 so this is not just about desktop. It affects Firefox on Android, too.

Also I do not want this replaced by some algorithm guessing what I mean even better. I have the aforementioned set of ~25 bookmarks tuned to 1 and 2 (raaaarely 3 or more) characters for quick access on mobile. Well, HAD tuned them for quick access on mobile, that is, now that they're gone. My combinations will not make any sense to any algorithm you can come up with. Replacing this with an extension that can't work on Android (because the API is not supported right now, and might be restricted even once it may or may not be supported) does not sound appealing. Using an extension that then has to be safeguarded by an additional prefix is also breaking this feature.

All I want is an amazing feature to not be broken on android any longer (ticket linked above) and to not break it on desktop (this ticket here).

(In reply to Marco Bonardo [:mak] from comment #30)

(In reply to megancutrofello from comment #29)

Would you be willing to consider a preference to disable the requirement of the additional keyword prior to the omnibox api suggestions?

Not for now, that magic keyword exists to avoid malicious add-ons from taking control of the urlbar. While that may look like an advanced feature, we really don't want to take that risk considered how search engines and the homepage were abused in the past.

Sorry, just to clarify my suggestion/request here, when I said preference, I meant something buried in about:config, so it would definitely be a power-users-only thing. The additional keyword makes ominibox api pretty offlimits to me currently so I'd really like some solution to this.

(In reply to megancutrofello from comment #29)

(In reply to Marco Bonardo [:mak] from comment #28)

(In reply to jscher2000 from comment #26)

What is intended to happen to bookmarks whose location does not contain =%s that I have assigned a keyword?

It is still under discussion, but ideally a good autofill and ranking algo should remove any need for them. Their main use case, as far as we can tell, is to cover url autofill missings.

What do you mean by this? For example I use lolcssme as a keyword for https://lol.gamepedia.com/Special:MyPage/common.css - this couldn't possibly autofill here.

Currently, I can type my keyword and press Enter to load the bookmarked URL. This is a non-search use of a keyword. The strings are too common to select from history. Without the keyword, I would need to filter using * to find my bookmark.

Conceivably an Omnibox extension could give you access to bookmarks by matching keyword text coded into the title, for example, if it's mcl:

My Crazy Life --mcl

Putting the keyword in the bookmark name will be a bit uglier, but I think we can be certain no one is going to deprecate bookmark names, and this takes advantage of automatic bookmark backups and Sync, which are more reliable than extension storage.

Unfortunately, the Bookmarks API doesn't include any feature to access the keywords, so the user will need to participate in the migration process. Since a bookmark export includes the keywords (SHORTCUTURL attribute), it might be possible for an extension to extract them from that file for its purposes once they are deprecated, assuming they aren't physically removed from the Places database before it's too late (for example, if they could stick around until at least the next ESR).

Or, comparing the deprecation of Live Bookmarks, creating an export file (not .opml, but something) could be helpful.

Note to future self: If it's too late to export but there is a .jsonlz4 backup from the right time period, I have a tool that can extract a list of the keyworded bookmarks: https://www.jeffersonscher.com/ffu/bookbackreader.html

(In reply to megancutrofello from comment #31)

What if it only applied to developer/local addons? This way there's still SOME recourse for maintaining true bookmark keyword functionality, and I can code my own tool, which is somewhat similar to writing bookmarklets.

You can write experimental WebExtension APIs that basically do whatever you wish in Nightly and DevEdition, see https://firefox-source-docs.mozilla.org/toolkit/components/extensions/webextensions/basics.html#webextensions-experiments.

I definitely don't want lol autocompleting to this page. Here's how lol autocomplete currently looks: https://puu.sh/H4MnA.png

Normal urlbar matching can do a good job even without having to remember hundreds of keywords, why wouldn't you just type "lol something" and pick a result that is at a DOWN of distance?

(In reply to Claudius from comment #32)

Please tell that to @Mugurell and @kbrosnan on GitHub, who closed and even LOCKED that issue pointing at this one here: https://github.com/mozilla-mobile/fenix/issues/12099#issuecomment-704143064 so this is not just about desktop. It affects Firefox on Android, too.

That seems right, Android won't implement keywords if desktop plans to change or deprecate them. I'm just saying that Android development won't happen here.

(In reply to megancutrofello from comment #33)

Sorry, just to clarify my suggestion/request here, when I said preference, I meant something buried in about:config, so it would definitely be a power-users-only thing.

Malicious programs can easily flip prefs, or convince users to do it.

(In reply to jscher2000 from comment #34)

Currently, I can type my keyword and press Enter to load the bookmarked URL. This is a non-search use of a keyword. The strings are too common to select from history. Without the keyword, I would need to filter using * to find my bookmark.

I'm interested in this, what's wrong with * when you already know you're looking for a bookmark? Is it just that you figure out later that you were looking for a bookmark?

Unfortunately, the Bookmarks API doesn't include any feature to access the keywords

That's because we knew keywords were a huge hack on top of bookmarks, adding an API would have forced us to keep them like that.

Or, comparing the deprecation of Live Bookmarks, creating an export file (not .opml, but something) could be helpful.

Fwiw, the plan would be to convert keywords to custom search urls, though only for the ones containing %s.
But AFAICT, the first step will be to introduce custom search URLs, then we may do the conversion... and only later we can start looking at remaining keywords deprecation. There's still quite some time to think about a solution for those. MAybe they could remain as "nicknames" for bookmarks, but there's problem with that, because users forget about keywords they set, and then file bugs asking why typing "car" went to "dealercar.site" instead of searching "car".

(In reply to Marco Bonardo [:mak] from comment #35)

(In reply to megancutrofello from comment #31)

I definitely don't want lol autocompleting to this page. Here's how lol autocomplete currently looks: https://puu.sh/H4MnA.png

Normal urlbar matching can do a good job even without having to remember hundreds of keywords, why wouldn't you just type "lol something" and pick a result that is at a DOWN of distance?

Because I have too many keywords for this to be practical. The common theme in this discussion seems to be that you want/think people use this feature, just not too much. Autocomplete doesn't work when there are 10+ URLs that all start with lol and all of my keywords are named hierarchically starting with lol then 2-6 characters to describe the rest of the function. Autocomplete also doesn't work when there are no consecutive characters in common in between the keyword and the target URL.

The problem is that this feature is most-heavily used by power users, and the current proposed solution most caters to casual users of it. So it's not going to satisfy use cases of the people who care about it the most.

MAybe they could remain as "nicknames" for bookmarks, but there's problem with that, because users forget about keywords they set, and then file bugs asking why typing "car" went to "dealercar.site" instead of searching "car".

Maybe some visibility could be provided by displaying the text (keyword) in the URL bar dropdown before the link when you're navigating that way? If you're at a URL that you have bookmarked with a keyword, in addition to the bookmark icon, it could display a 2nd icon or again literally the word "keyword" (or a tooltip saying keyword when you hover the bookmark icon).

Another option could be to display keywords in the bookmark menu, for example keyword:name or name (keyword), so they are more aware of their existences in general.

(In reply to Marco Bonardo [:mak] from comment #35)

(In reply to jscher2000 from comment #34)

Currently, I can type my keyword and press Enter to load the bookmarked URL. This is a non-search use of a keyword. The strings are too common to select from history. Without the keyword, I would need to filter using * to find my bookmark.

I'm interested in this, what's wrong with * when you already know you're looking for a bookmark? Is it just that you figure out later that you were looking for a bookmark?

It's really just about speed:

First, it's difficult to accurately hit Shift+8 by touch typing alone compared with, say, Ctrl+L and the regular letters used in the keyword.

Second, the autofill feature currently does not automatically select the best match among full URLs, you always need to arrow down, which is a character far away from the home row of the keyboard.

(I know all this talk of typing is very old fashioned, but... it is desktop.)

Or, comparing the deprecation of Live Bookmarks, creating an export file (not .opml, but something) could be helpful.

Fwiw, the plan would be to convert keywords to custom search urls, though only for the ones containing %s.
But AFAICT, the first step will be to introduce custom search URLs, then we may do the conversion... and only later we can start looking at remaining keywords deprecation. There's still quite some time to think about a solution for those. MAybe they could remain as "nicknames" for bookmarks, but there's problem with that, because users forget about keywords they set, and then file bugs asking why typing "car" went to "dealercar.site" instead of searching "car".

That's good to know.

Already the keyword field is hidden in the Add/Edit Bookmark dialog that most users use, and that may have been the case since Firefox 29 (hard to remember). So as long as "Add a keyword for this search..." creates an engine in the future instead of a bookmark I think the number of support issues should go way down.

(In reply to jscher2000 from comment #37)

First, it's difficult to accurately hit Shift+8 by touch typing alone compared with, say, Ctrl+L and the regular letters used in the keyword.

Second, the autofill feature currently does not automatically select the best match among full URLs, you always need to arrow down, which is a character far away from the home row of the keyboard.

(I know all this talk of typing is very old fashioned, but... it is desktop.)

I agree with both those points (and I should hope desktop/keyboard does still get its due consideration ... I'm not suggesting it isn't)

Most of the prefixes like that ($, %, ^, &, *) are pretty poor for keyboard speed.

'?' (for search) is about the best because it's modifier-adjacent, likely to be well-trained in user's muscle memory, and in consistent position on most keyboards (I think?). Which is sort of a waste really, when the current browser behaviour already assumes search to be the default desired action in the addressbar.

wrt your discussion about keyword bookmarks without substitutions, I note that '+' prefix filters to tagged bookmarks. Assuming tags are not going away, that is another "good key" on most keyboards and with appropriate tag creation and management it can serve that use-case quite efficiently, I think.

However at present, using it still yields a search as the default option (so you must still arrow-down to select a tagged bookmark result). Why is this? Surely the '+' indicates you do not want to do a search?

NB I'm aware that Google search understands the '+' in its own syntax as well so you might indeed wish to start a search query with that character; but that is a secondary level to the syntax you type (the primary being what you want the browser to do), so it seems to me that if you wish to specify a search for "+blahblah" you should type "? +blahblah". No?

Please let's try to stay on topic, restriction characters bugs should be discussed elsewhere. I only asked a direct question about * usage because it was brought out as a plausible workaround.

I was chiefly addressing the same point, and presenting a workaround that jscher2000 and others concerned with the fate of non-parametrised keyword bookmarks (which is in the scope of this bug) might find more keyboard-efficient than '*'. In connection to this I presented a caveat that hinders both. I apologise if I did so in too discursive a manner.

I'm happy to find and join, or start, another bug on the matter of restriction characters being overridden by search, but until and unless said bug is acknowledged and acted upon, which is far from a given, it remains a negative factor against solutions involving restriction-characters being agreed as the appropriate way forward for current users of non-parametrised keyword bookmarks when they are discontinued.

Please don't post these long analysis in bugs, you're spamming everyone cc-ed to the bug, and making the bug unreadable. You can contact us on Matrix, send us an email, or if you want to discuss a proposal with people just post on Reddit and we can answer there (just tag mak-77).
There are a few misunderstandings in what you wrote, but if I should answer here the bug would become even worst. This is still a technical tracker, so please refrain from long feedback threads and keep those in places where we can handle them.

You need to log in before you can comment on or make changes to this bug.