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

Steps to reproduce:

using * in address bar to list bookmarks.
using % in address bar to list current open tabs.

Actual results:

Always search engine suggestions (one-click search) precedes the actual query results.

Expected results:

Search engine for internal firefox query should have been disabled.

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

I'm sorry, I can't understand your report. What in the screenshot are you expecting to see/not see?

firefox has inbuilt query filter,
* <followed_by_text>
used to search bookmarks and navigate to it
% <follwed_by_text>
same goes for currently active tabs

Search suggestion precedes this (which don't make much sense in context of search query), so I have to press 'down' to choose from the list.
The screen shot shows duckduckgo (in my case) is in top of the list.

I have added another screenshot which should give a better idea.

A similar behavior is happening with short domains that are enabled with a DNS.

Typing in go/search-term used to open up http://go/search-term in Firefox 77.
Now in Firefox 78,
Typing in go/search-term only does a Search Suggestion for "go/search-term"

(In reply to Sean Burke from comment #4)

A similar behavior is happening with short domains that are enabled with a DNS.

Typing in go/search-term used to open up http://go/search-term in Firefox 77.
Now in Firefox 78,
Typing in go/search-term only does a Search Suggestion for "go/search-term"

Please see Bug 1642435 there are prefs you can set to customize the behavior, or just type "go" and see the notification you get.

(In reply to hisacro from comment #3)

Search suggestion precedes this (which don't make much sense in context of search query), so I have to press 'down' to choose from the list.
The screen shot shows duckduckgo (in my case) is in top of the list.

I see, that is the expected behavior currently, and it always worked like that.
The first preselected row just tells you what happens when you press Enter after typing, it is common to most browsers.

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

The first preselected row just tells you what happens when you press Enter after typing, it is common to most browsers.

I highly doubt other browsers have internal query.

I'm not sure what you mean, in any browser if you type text you get a preselect line saying what happens when you press Enter.

I believe the point is that other browsers don't have a concept of "filter-tokens" in urlbar, thus they don't worry about it.

Let's say you bookmark a page like wikipedia. Then you open a tab and type * wiki:

In Firefox this would show a list of bookmarks that match wiki
In Edge (and probably other chromium browsers, although I didn't test) it would just give you results of some heuristic, but they would not be limited to just bookmarks.

If you did not start your query with * - then the results in Firefox will also use some "automatic" heuristic.

Now, the fact that the pre-selected row should show what happens if you press enter is correct behavior. What OP is arguing about is that if the user manually starts the query with one of the "filter tokens" - *,#,% etc. - then the pre-selected item SHOULD NOT BE a search item - it should be the first result that matches the current filter token.

You could argue that this makes it hard to actually search for stuff that begins with one of the filter tokens, but really that's got to be pretty rare - and one could also just prefix those searches with ? token. So it's not a very sound argument.

Honestly I think this proposal makes a lot of sense since it would make using these filter tokens much more convenient.

(In reply to jastekken from comment #9)

Let's say you bookmark a page like wikipedia. Then you open a tab and type * wiki:

So what do you expect to happen if you type "* wiki" and press Enter? You may say "I expect the top bookmark to load", but while that is clear to you, because you know about the undiscoverable "*" behavior, to the common user it will look like we loaded a seemingly random page.

I suspect Bug 1644572 will have to go the "do nothing" direction when in search mode, Enter may do nothing, or will have to search, that is clearly not what the user wants.

Indeed I would expect the top bookmark to load. You are correct the filter tokens are pretty undiscoverable, which itself is a separate topic but I would point out that they are a super useful feature that should be made more discoverable.

The top item is pre-selected which itself is a pretty obvious hint to the user about what is going to happen when they hit enter. It's certainly not random. And even if for some reason it wasn't obvious the risk that the user by accident started their query with one of the filter tokens is pretty small.

Regardless, the current behavior is at least equally confusing. Me as a user type % wiki fully expecting a list of open tabs since I explicitly asked to do so. But for some "random" reason Firefox seems to think that I want to do a search instead.

Actually, the current behavior is pretty bad especially for "switch-to-tab" function. Some recent update added a "search tabs" item to the all-tabs-button popup. The way that works is that it activates urlbar and adds a % filter. When used through the popup, the user would absolutely not under any circumstance expect Firefox to do a search for whatever they type but find a matching tab to activate. This same argument fully applies to * token which may be added automatically when using Bookmarks popup panel to search bookmarks.

I suspect Bug 1644572 will solve some of these behaviors, though we'll be left with the old manually typed tokens case.
Let's mutate this to evaluate what to do.

Unless I'm missing something, * wiki and % wiki now enter Bookmarks and Tabs search modes, respectively, and there is no search heuristic. I'd say this is resolved.