Open Bug 1631321 Opened 4 years ago Updated 2 years ago

URL fragment matching address bar query can seriously dominate search results

Categories

(Firefox :: Address Bar, enhancement, P3)

75 Branch
enhancement
Points:
5

Tracking

()

People

(Reporter: rob, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

I use a wiki called TiddlyWiki, which uses URL fragments to track which documents in the wiki are currently open (ex. https://tiddlywiki.com/#HelloThere:HelloThere%20GettingStarted%20Community has the "HelloThere", "GettingStarted", and "Community" pages open). As I use the wiki, I will reorder, close, or open pages, resulting in many distinct pages as far as moz_places is concerned. These pages have come to seriously clutter my address bar search results.

Actual results:

I see address bar search results pretty much exclusively from my wiki's domain when I search for certain terms. For example, when I typed in "coroutine" in the address bar just now, these were my top five results:

  • TiddlyWiki - mywiki/#:[[Pending name]][[Blog Post: Lua Coroutines Can Make Async Code More Straightforward]] [[Blog about continuations]] [[Regularly review journal entries]]
  • TiddlyWiki - mywiki/#:2020-04-08 [[Blog Post: Lua Coroutines Can Make Async Code More Straightforward]] [[Blog about continuations]] [[Regularly review journal entries]]
  • Lua 5.3 Reference Manual - lua.org/manual/5.3/manual.html/#pdf-coroutine.running
  • TiddlyWiki - mywiki/#:2020-04-06 2020-04-05 [[Blog Post: Lua Coroutines Can Make Async Code More Straightforward]] [[Blog about continuations]] [[Regularly review journal entries]]
  • TiddlyWiki - mywiki/#:2020-04-11 2020-04-12 2020-04-13 2020-04-14 [[Firefox: blacklist/deprioritize sites for address bar]] [[A Deepness in the Sky]] [[Blog Post: Lua Coroutines Can Make Async Code More Straightforward]]

Note how the "Blog Post: Lua Coroutines Can Make Async Code More Straightforward" page is present in the fragment each time (because it's open in my wiki) but the other pages present in the fragment vary from result to result (typically as I review/edit journal entries from previous days)

Expected results:

One of the following:

  • The number of times a URL that varies only by fragment should be reduced
  • A user should have the ability to blacklist a domain from contributing to awesome bar search results.
  • Expose a WebExtension API to manipulate keyword-less address bar search results so users can deal with web applications like these on a case-by-case basis.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Address Bar

Thanks for filing the bug.
This is something to evaluate with care, we were already brainstorming something for bug 1389229, there are of course pitfalls here per https://bugzilla.mozilla.org/show_bug.cgi?id=1389229#c3

We must also consider that frecency score is based on visits, bookmarks, but not on search terms (it's not scoring how well words match against a result), as such it's complicate to handle things like "lower score if it matches the ref, higher if it matches the domain", and so on.

What we can do atm is mostly post-search filtering, where discerning duplicates and matching may not be trivial.
This is up for further brainstorming.

Points: --- → 5
Priority: -- → P3
See Also: → 1389229
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.