Open Bug 1650874 (search-alias) Opened 5 years ago Updated 17 days ago

[meta] Consolidate search alias and keyword usage / Rework the search preferences UI

Categories

(Firefox :: Search, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: daleharvey, Unassigned)

References

(Depends on 8 open bugs, Blocks 8 open bugs, )

Details

(Keywords: meta, Whiteboard: [sng-scrubbed])

No description provided.

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

Depends on: 1650880
Depends on: 1650881
Depends on: 1650883
Depends on: 1650887
Depends on: 1106626
Depends on: 1650892
Depends on: 1650894
Priority: -- → P3
Depends on: 1653261
No longer depends on: 1650894
No longer depends on: 1106626
No longer depends on: 1650892
Depends on: 1658713
Depends on: 1664566
Blocks: 1673115
Blocks: 1546652
Blocks: 1673696
Blocks: 1668484
Summary: [meta] Consolidate search alias and keyword usage → [meta] Consolidate search alias and keyword usage / Rework the search preferences UI
Blocks: 1446359
Blocks: 1587983
Depends on: 1661664
Blocks: 1689986
Blocks: 1195005
Severity: -- → N/A
Depends on: 1759879
Depends on: 1310666
Depends on: 1802891
Blocks: 1805403
No longer blocks: 1689986
Duplicate of this bug: 1653261
Duplicate of this bug: 1172366
Duplicate of this bug: 648398

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.

Whiteboard: [sng-scrubbed]
Depends on: 1893587
Depends on: 1893594

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.

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

(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?

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.

Depends on: 1895514

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.

Depends on: 1901843
No longer depends on: 1901843
Duplicate of this bug: 1902916
Depends on: 1918890
Depends on: 1915289
No longer depends on: 1918890
Duplicate of this bug: 1929547
Blocks: 1907119
Depends on: 1944070
You need to log in before you can comment on or make changes to this bug.