[meta] Consolidate search alias and keyword usage / Rework the search preferences UI
Categories
(Firefox :: Search, enhancement, P3)
Tracking
()
People
(Reporter: daleharvey, Unassigned)
References
(Depends on 8 open bugs, Blocks 8 open bugs, )
Details
(Keywords: meta, Whiteboard: [sng-scrubbed])
Reporter | ||
Comment 1•5 years ago
|
||
I have written up a little summary of the project @ https://docs.google.com/document/d/1G65IlLQqooUnRFtrzi-FU79MbPpSG0MNJ6F8zXV4z8g/edit which is based on Marks investigation
Updated•5 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•3 years ago
|
Comment 7•10 months ago
|
||
This should be included as part of the Search preferences improvement initiative. Something to keep in mind is how to consolidate how aliases are presented in a consistent manner across UI surface areas.
Updated•10 months ago
|
Comment 8•10 months ago
|
||
Would it be possible to re-open bug 1675996 and mark it as a blocker of this bug? That seems like a pretty significant feature of bookmark keywords that's missing from the search UI.
Comment 9•10 months ago
|
||
(In reply to David Mandelberg from comment #8)
Would it be possible to re-open bug 1675996 and mark it as a blocker of this bug? That seems like a pretty significant feature of bookmark keywords that's missing from the search UI.
Sorry, but we do not think that is a option that's of benefit to users. There's various alternatives like just typing a couple of letters and letting autofill do the work.
Comment 10•10 months ago
|
||
(In reply to Mark Banner (:standard8) from comment #9)
There's various alternatives like just typing a couple of letters and letting autofill do the work.
Doesn't that only work if the keyword is a substring of the URL or title? Also, that seems unreliable since it would be influenced by what sites are recently visited. And would it work at all for a site that hasn't been visited at all in the browser's stored history?
Comment 11•10 months ago
|
||
If you mean that bookmark keywords should be retained for non-search purposes, we can evaluate their existence by renaming the feature to "nickname", a bookmark may have a nickname to retrieve in the address bar, but it would just be a plain string with no search purposes. This is something we're still pondering about, as otherwise that functionality would get lost.
If instead you mean it should be possible for a search keyword to visit the site homepage when the search string is empty, then it's unlikely to happen, as we think there's better alternatives. bug 1675996 was covering mostly this as it was about "searching empty strings" so it won't be reopened.
Comment 12•10 months ago
|
||
Bookmark keywords for non-search purposes (nicknames) are very useful for me. I often change long URLs into short keywords using this, and it is nice to know that it will always be exactly the same url, not have to search among the offered suggestions, which might change place depending on sync status and recent history. As an example, I have they keyword "black" assigned to a data:image/svg+xml bookmark that loads a black screen-filling svg with an impossibly long name.
My reading of the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1653261 suggests that the main objections to removing keywords are (1) javascript bookmarklets and (2) nicknames. Given the general deprecation of javascript: urls, I think requiring an extension for the functionality of (1) is reasonable. for (2), however, I would have to create a separate extension for each nickname that I currently have which seems excessive and cumbersome.
Updated•6 months ago
|
Description
•