1659309 - Searching for URLs in search mode with non-"Web" engines is not possible

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P2)

Description

[Caspy7]

Seems to be a regression starting with the new URL behavior for Searches.

I'm on the latest Nightly. Another nightly user reproduced this on Linux.

I have a common pattern where I do a twitter search on URLs to find associated tweets. This was working fine up until recently.
The URL may have been pasted or already be in the address bar (when viewing the page).

STR:

• Install the click to search twitter addon at
  https://addons.mozilla.org/en-US/firefox/addon/twitter-one-click-search/
• Visit a page or paste a URL in the address bar
• Focus the URL bar so the current URL is highlighted
• Click the twitter search
• Hit enter

Expected results: Search Twitter for the URL
Actual results: The tab visits the URL in question.

I'm annoyed that the new behavior forces an extra step in order to accomplish the same thing I was doing before, but even more unfortunate is that it's completely broken.

Comment 1

[Drew Willcoxon :adw]

Unfortunately this is the expected behavior with the urlbar's new work-in-progress search mode. The one-off search engine buttons are no longer one-click searches. Instead they put the urlbar into search mode. We already have a wontfixed bug on file for this, so I'll dupe this there. I forwarded the existing bug to UX so that they're aware of the user feedback, and I'll forward this one too.

One thing we could do is to add any extension APIs necessary so that at least extensions could implement one-click searches. They might already be able to do that today, I'm not sure off hand.

Comment 2

[Drew Willcoxon :adw]

Sorry, wrong bug, I meant bug 1658994.

Comment 3

[Caspy7]

Guess it was my fault for including too much information.
My bother about the extra step in the new UX is separate from the bug I filed. You can ignore it if you like.
I have here described genuine brokenness in which the search "doesn't work".
Someone else also followed these steps and found the same problem (nothing to do with the extra step). Please attempt to reproduce.

Comment 4

[Drew Willcoxon :adw]

It's not as simple as saying "it doesn't work." All that add-on does is install a new search engine and add it to the urlbar. It got the one-click behavior for free because previously that's how all engines in the urlbar worked. But that's not how they work anymore. That extension is either going to need to rename itself to reflect Firefox's new behavior, or it will need to be rewritten so it still does one-click searches.

Comment 5

[Danny Colin [:sdk]]

The issue here isn't about the extra step but the fact that you can't pass an URL as an argument/search terms. So for example @keyword https://example.com won't search for the URL on @keyword but it will open https://example.com website.

Comment 6

[Caspy7]

If I paste or type some text into the address bar, click twitter, Twitter is now appended to the front - giving me the expectation I'm about to do a twitter search. Hit enter and a twitter search is executed on the text. I arrive at twitter. My expectation is fulfilled.

If I paste or type a URL into the address bar, click twitter, Twitter is now appended to the front - giving me the expectation I'm about to do a twitter search. Hit enter and I am taken to the URL rather than Twitter. My expectation was not fulfilled.

Comment 7

[Drew Willcoxon :adw]

I'm sorry for not reading closely enough. You're right, at step 5 in comment 0, we should do a Twitter search for the URL, not visit the URL.

Comment 8

[Drew Willcoxon :adw]

This is a regression from bug 1658646 and affects all non-"Web" engines.

Comment 9

[Drew Willcoxon :adw]

Attachment: Bug 1659309 - UrlbarProviderHeuristicFallback should return a search heuristic when in search mode, not a URL heuristic, even when not restricting results to search.

Comment 10

[Drew Willcoxon :adw]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=52e7d98c0fe6836133450713b5b912dfbac3bf2a

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1658646

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4b8de762e097
UrlbarProviderHeuristicFallback should return a search heuristic when in search mode, not a URL heuristic, even when not restricting results to search. r=harry

Comment 13

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/4b8de762e097

Comment 14

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I verified this issue using 82.0a1 (2020-09-14) on macOS 10.13 and Windows 10 x64.
Adrian could you help me with Ubuntu verification?

Comment 15

[Adrian Florinescu [:aflorinescu]]

I have some doubts related to the corectness of comment 0 STR (steep 3) followed in the expected functionality.
If you input hyperlink manually or edit one and hit an one-off, it works correctly. But if you do for example, the following:

1. Select youtube from topsites.
2. Select addressbar (https://youtube.com is highlighted)
3. Set the cursor at the start or at the end of https://youtube.com (to remove the highlight).
4. Click an one-off.

the result would be that the hyperlink is deleted and i get [one-off search-mode] and I think my expectancy would be that once I remove the hyperlink highlight i would get [one-off search-mode] hyperlink.

Drew, can you please clarify what should happen in the case in which the hyperlink highlight is specifically removed and an one-off is selected?

Comment 16

[Drew Willcoxon :adw]

the result would be that the hyperlink is deleted and i get [one-off search-mode]

Yes, this is the expected result. The key point isn't the highlight but the "page proxy state," which basically means whether the text in the input has been edited. When the text is still the URL of the current page and you haven't modified it, then the page proxy state is valid, and the urlbar shows a shield and lock icon (if the page is secure). When you edit the text in the input, then the page proxy state becomes invalid, and the shield and lock icon are replaced with a search icon.

When the page proxy state is valid (shield and lock icon), entering search mode clears the input. When it's invalid (search icon), entering search mode keeps the text you've edited.