Closed Bug 1800380 Opened 2 years ago Closed 2 years ago

Firefox address bar: typing a few letters and then clicking the first item in the drop-down runs a (Google) search on the text fragment instead of accessing that first URL (when using dns_first_for_single_words)

Categories

(Firefox :: Address Bar, defect, P1)

Product:
Firefox
Component:
Address Bar
Version:
Firefox 106
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
109 Branch
Tracking Flags:
Tracking Status
firefox-esr102 --- unaffected
firefox107 - wontfix
firefox108 + verified
firefox109 + verified

People

(Reporter: bugzilla-mozilla-only-for-adi-20160420, Assigned: daisuke)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [snt-scrubbed] [search-papercut])

Attachments

(3 files, 1 obsolete file)

firefox-typed-slug-address-bar-bug.png
31.91 KB, image/png
Details
firefox-typed-slug-cause-description.txt
110 bytes, text/plain
Details
Bug 1800380: Unselect the selected element after pickElement().
48 bytes, text/x-phabricator-request
dmeehan
: approval-mozilla-beta+
dmeehan
: approval-mozilla-release-
Details | Review

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0

Steps to reproduce:

  1. visit a random website... e.g. https://example.com/
  2. add it to bookmarks (i added it to "Other Bookmarks" in my case, but i think it might work with any bookmarks section)
  3. open a fresh tab (or window), close the old one
  4. start typing the first few letters of that bookmarked address (e.g. "exam" in the case above)
  5. CLICK (do not press Enter) on the first item that appears in the automatic drop-down (it should be the previously bookmarked URL)

note: i will check the "security" report checkbox in the bug submission form because this bug could result in accidental data leaks of typed data to search engines or unintended visits to other sites.

Actual results:

browser starts to run a (Google) search for the typed text fragment instead of accessing the site.

Expected results:

Browser should access the selected URL instead of sending the typed fragment to a search engine.

adding a screenshot of my current address suggestion settings from about:config

Summary: Firefox address bar: typing a few letters and then chosing the first item runs a (Google) search instead of accessing the url → Firefox address bar: typing a few letters and then choosing the first item runs a (Google) search instead of accessing the url

update: i managed to reproduce this bug in the 107.0b9 (64-bit) developers edition of Firefox.

setting the preference "browser.fixup.dns_first_for_single_words" to TRUE will cause this behaviour to happen.

Seems that another attachment is needed if i want to mark as obsolete the previous attachment with the about:config settings for suggestions settings.

Attachment #9303209 - Attachment is obsolete: true
Summary: Firefox address bar: typing a few letters and then choosing the first item runs a (Google) search instead of accessing the url → Firefox address bar: typing a few letters and then choosing the first item in the drop-down runs a (Google) search on the slug instead of accessing that first URL
Summary: Firefox address bar: typing a few letters and then choosing the first item in the drop-down runs a (Google) search on the slug instead of accessing that first URL → Firefox address bar: typing a few letters and then choosing the first item in the drop-down runs a (Google) search on the text fragment instead of accessing that first URL

possible related bugs:
https://phabricator.services.mozilla.com/D50051
Summary: Bug 1588118 - use the right flag to guard search service use from the URI fixup code, r?mak

https://bugzilla.mozilla.org/show_bug.cgi?id=1588118
Summary:Investigate why URIFixup may fixup to a search when only FIXUP_FLAG_FIX_SCHEME_TYPOS is passed-in

this one next one is ALMOST similar, but pressing Enter will go to that first URL, this time it is the CLICK action that causes the search problem
https://bugzilla.mozilla.org/show_bug.cgi?id=1663577
Summary: Editing URI in URI bar and pressing Enter goes to search instead of loading new URI

Because this isn't something a remote attacker can cause to happen, and because security bugs aren't normally accessible except to a very small set of people, and we should try to get this bug fixed as quickly as possible, I'm removing the flag.

Group: firefox-core-security
Component: Untriaged → Address Bar
Summary: Firefox address bar: typing a few letters and then choosing the first item in the drop-down runs a (Google) search on the text fragment instead of accessing that first URL → Firefox address bar: typing a few letters and then clicking the first item in the drop-down runs a (Google) search on the text fragment instead of accessing that first URL (when using dns_first_for_single_words)

[Tracking Requested - why for this release]:
Not doing the thing the UI promises to the user is bad.

Status: UNCONFIRMED → NEW
status-firefox107: --- → affected
status-firefox108: --- → ?
status-firefox109: --- → ?
tracking-firefox107: --- → ?
Ever confirmed: true

User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:107.0) Gecko/20100101 Firefox/107.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:108.0) Gecko/20100101 Firefox/108.0

  • noticed that Firefox 107.0 stable was released, so i upgraded to it ...
  • also upgraded Firefox Developer to version 108.0b1 (64-bit) ...

... the same wrong behaviour happens with browser.fixup.dns_first_for_single_words = true in both versions.

Reproduced on latest Nightly 109.0a1 with browser.fixup.dns_first_for_single_words set to True.

Mozregression points to bug 1784455 (run it twice, because this issue doesn't seem related).

Found commit message: Bug 1784455: Unselect element selected by mouse even if mouseup at anywhere. r=adw

Keywords: regression
Regressed by: 1784455

:daisuke, since you are the author of the regressor, bug 1784455, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Flags: needinfo?(daisuke)

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

status-firefox-esr102: --- → unaffected

Clearing the selection in mouseup, without any checks, seems quite scary to me. I think we should, at a minumum, check the mouse is not hovering the results panel anymore.
I think the problem here is that we check and navigate to the selected result after mouseup, at that point the listener has cleared the selection.

Severity: -- → S2
Priority: -- → P1

Thank you for the report!
I take a look at this issue.

Assignee: nobody → daisuke
Status: NEW → ASSIGNED
Flags: needinfo?(daisuke)
Whiteboard: [snt-scrubbed] [search-papercut]
Pushed by dakatsuka.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6ecb3a8b642d
Unselect the selected element after pickElement(). r=adw

https://hg.mozilla.org/mozilla-central/rev/6ecb3a8b642d

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
status-firefox109: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 109 Branch

The patch landed in nightly and beta is affected.
:daisuke, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox108 to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(daisuke)

STR for QA:

Please verify this bug is fixed and the issue of bug 1784455 does not happen.

For this bug with browser.fixup.dns_first_for_single_words pref:

  1. Turn on browser.fixup.dns_first_for_single_words pref.
  2. Open https://example.com.
  3. Bookmark it.
  4. Open a new tab.
  5. Close tab that has opened https://example.com.
  6. Type “ex” on the urlbar. Verify the first row result is for the page of https://example.com.
  7. Click the row. Verify https://example.com is opened.

For this bug without browser.fixup.dns_first_for_single_words pref:

  1. Turn off browser.fixup.dns_first_for_single_words pref.
  2. The rest is the same as above…

For bug 1784455:

  1. Open a new tab.
  2. Click on the urlbar. Verify the urlbar result is opened and there are quick action buttons on the result.
  3. Mouse down on one of quick action button. Verify the background color is changed to the selected color.
  4. While holding mouse down, move mouse to out side of the urlbar result. Verify the background color is still selected color.
  5. Mouse release. Verify the background color is changed to normal color.
Flags: needinfo?(daisuke) → qe-verify+

Comment on attachment 9304006 [details]
Bug 1800380: Unselect the selected element after pickElement().

Beta/Release Uplift Approval Request

  • User impact if declined: In case of that “browser.fixup.dns_first_for_single_words” is true, when clicking on the urlbar result, may open unexpected page.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Please see comment 17.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This revision is to change only the order of processing for mouse release for urlbar results.
  • String changes made/needed: None
  • Is Android affected?: No
Attachment #9304006 - Flags: approval-mozilla-beta?
QA Whiteboard: [qa-triaged]

I have reproduced this issue on Firefox 108.0b5, on Windows 10, following the STR from comment 0 and comment 17 with the pref 'browser.fixup.dns_first_for_single_words' set to true.
This issue is verified as fixed on Firefox 109.0a1 (20221123213526) on Windows 10, Ubuntu 21.04 and macOS 10.15. Regardless of the pref setting (true or false), when typing a few letters and then clicking the first item in the drop-down the browser is opening the bookmarked URL and does not perform a Google search.
Also, I have verified that the issue of bug 1784455 is not reproducible.

Leaving the qe-verify+ flag until this gets verified in beta as well.

status-firefox109: fixed → verified

Comment on attachment 9304006 [details]
Bug 1800380: Unselect the selected element after pickElement().

Approved for 108.0b6.

Attachment #9304006 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Verified as fixed on Firefox 108.0b6 (20221124185931) on Windows 10, Ubuntu 22.04 and macOS 10.15.

status-firefox108: fixed → verified
Flags: qe-verify+

:daisuke, given the severity rating on this, would like to consider this in a dot release ride-along?
Could you add a release uplift request when ready?

Flags: needinfo?(daisuke)

Thank you, Donal.
Okay, I will do it.

Flags: needinfo?(daisuke)

Comment on attachment 9304006 [details]
Bug 1800380: Unselect the selected element after pickElement().

Beta/Release Uplift Approval Request

  • User impact if declined: In case of that “browser.fixup.dns_first_for_single_words” is true, when clicking on the urlbar result, may open unexpected page.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Please see comment 17.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This revision is to change only the order of processing for mouse release for urlbar results.
  • String changes made/needed: None
  • Is Android affected?: No
Attachment #9304006 - Flags: approval-mozilla-release?
Flags: qe-verify+

There are conflicts in release with browser/components/urlbar/UrlbarView.sys.mjs
Sorry :daisuke, could you add a patch rebased onto release? We could include it as a ride along in the next dot release

Flags: needinfo?(daisuke)

Hi Donal! Thank you very much.
I have one question.
I have never rebased to release before, what repository should I rebase to (what repository should I clone)?

Flags: needinfo?(daisuke) → needinfo?(dmeehan)

https://hg.mozilla.org/releases/mozilla-release/

When grafting https://hg.mozilla.org/mozilla-central/rev/6ecb3a8b642d there are conflicts browser/components/urlbar/UrlbarView.sys.mjs

It's too late to fix for 107.0.1, but if you could attach a patch that grafts cleanly then I'll include it as a ride along if we have another 107 dot release.

Flags: needinfo?(dmeehan)
Status: RESOLVED → VERIFIED

Comment on attachment 9304006 [details]
Bug 1800380: Unselect the selected element after pickElement().

Rejecting 107 release uplift
108 is going to RC on 2022-12-05, we don't have a suitable dot-release vehicle before 108 goes live.

Attachment #9304006 - Flags: approval-mozilla-release? → approval-mozilla-release-

Removing the qe-verify+ flag as this was verified on fixed versions.

QA Whiteboard: [qa-triaged]
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: