Open Bug 1527053 Opened 2 years ago Updated 2 months ago

Can't quicksearch for a term that's used as a bug alias


( :: Search, defect)

Not set




(Reporter: erwinm, Unassigned)




(1 file)

46 bytes, text/x-github-pull-request
Details | Review

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:65.0) Gecko/20100101 Firefox/65.0 Waterfox/56.2.7

Steps to reproduce:

I searched "video" to find out whether Firefox can inspect, block, kill, and permanently kill pop-up videos. (I don't enjoy migraines.)

Actual results:

I got redirected to:

Bug 382267 (video)
Implement WHATWG Video spec

Expected results:

Maybe "video" would have returned too many results, but this doesn't help.

"kill video" doesn't show relevant results.

I bet this will be handled by some of the search UX kohei is planning, so I won't speculate on how to improve that at the moment.
But the immediate issue, quoting "video" will do what you want.

Severity: normal → enhancement
Component: General → User Interface
Ever confirmed: true

I think the current Quick Search behaviour can be fixed so words won’t match aliases. Bug # is probably fine, but words should not be treated as aliases. Instead, we can show any matched bugs in the dropdown list I’m developing in Bug 1472565.

Component: User Interface → Search

Basically this bug can be solved by removing this line: Bugzilla/Search/

Attached file GitHub Pull Request
Assignee: nobody → kohei.yoshino

Merged to master.

Closed: 2 years ago
Resolution: --- → FIXED
Resolution: FIXED → ---
Type: enhancement → defect
No longer blocks: 1540245
Regressions: 1540245
See Also: → 1472565

This could be solved by adding a URL param like redirect_alias=0 only to the quick search forms.

Assignee: kohei.yoshino → nobody
Duplicate of this bug: 1650500

bug 1640769 defines this better

(In reply to MarjaE from comment #8)

bug 1640769 defines this better

I agree. Here's the description from bug 1640769:

Aliases are great to name important bugs, but sometimes they get in the way of doing real searches.

E.g., If I wanted to search for bugs that mention "tsan", I'd get from to the same page as (i.e., just one bug, instead of the list I expected).
And from there, if I really wanted to search for bugs that mention "tsan", I would need to click "Advanced Search", type "tsan" again and enter. It's fairly simple, but it can be a little frustrating, especially with common words.

So I would suggest that when landing on a bug from a quicksearch with an alias, there should be a link near the top, saying something like "<word> is an alias for this bug. If you want to do a search for bugs mentioning <word>, click here".

Bonus: Maybe it could be an option to "quicksearch", so it's easy to create a keyword-search in Firefox?

Also updating the summary to better reflect the issue and make it more searchable (ironically)

Summary: Can't search for "video" to find all relevant bugs → Can't quicksearch for a term that's used as a bug alias

Also, it's not clearly mentioned on this bug, you only figure it out if you follow the change history:

This got resolved once by making QuickSearch not resolve standalone aliases.
That broke a lot of people who depended on that functionality, so it was backed out as part of bug 1540245, and this bug was then reopened.

Personally I kind of like the idea proposed by :gerald on bug 1640769 to just go directly to the aliased bug like we used to (still?) do, and add a box at the top to re-run the quicksearch as an actual search. This would probably involve adding a URL param to quicksearch which would tell it to ignore alias resolution, which could be tacked on in the link in the disambiguation box. I suppose quicksearch would need to do something like tacking on "fromquicksearch=1" on the URL when it redirects to the bug, and then show_bug can set/clear a cookie around redirecting to itself to get rid of the param and display the box.

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