Closed Bug 1659309 Opened 6 months ago Closed 5 months ago

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

Categories

(Firefox :: Address Bar, defect, P2)

Firefox 81
defect
Points:
2

Tracking

()

RESOLVED FIXED
81 Branch
Iteration:
81.2 - Aug 10 - Aug 23
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox79 --- unaffected
firefox80 --- unaffected
firefox81 --- fixed

People

(Reporter: caspy77, Assigned: adw)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

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:

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.

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.

Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1659144

Sorry, wrong bug, I meant bug 1658994.

Duplicate of bug: 1658994

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.

Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

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.

Status: REOPENED → RESOLVED
Closed: 6 months ago6 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1658994

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.

Flags: needinfo?(adw)

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.

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.

Status: RESOLVED → REOPENED
Flags: needinfo?(adw)
Resolution: DUPLICATE → ---
Assignee: nobody → adw
Severity: -- → S3
Status: REOPENED → ASSIGNED
Iteration: --- → 81.2 - Aug 10 - Aug 23
Points: --- → 2
Priority: -- → P2

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

Keywords: regression
Regressed by: 1658646
Summary: Third Party click-to-search addons don't work with URLs in the address bar. → Searching for URLs in search mode is not possible
Summary: Searching for URLs in search mode is not possible → Searching for URLs in search mode with non-"Web" engines is not possible
Pushed by dwillcoxon@mozilla.com:
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
Status: ASSIGNED → RESOLVED
Closed: 6 months ago5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch

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?

Flags: needinfo?(adrian.florinescu)

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?

Flags: needinfo?(adrian.florinescu) → needinfo?(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.

Flags: needinfo?(adw)
You need to log in before you can comment on or make changes to this bug.