Closed Bug 1559625 Opened 4 months ago Closed 3 months ago

-search command line option not functioning in Windows

Categories

(Firefox :: Search, defect, P1)

67 Branch
defect
Points:
2

Tracking

()

VERIFIED FIXED
Firefox 70
Iteration:
69.3 - Jun 10 - 23
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- verified
firefox68 --- wontfix
firefox69 --- verified
firefox70 --- verified

People

(Reporter: ben.m.weller, Assigned: daleharvey)

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

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

Steps to reproduce:

Firefox 67.0.2 (64-bit) on Windows.

"firefox.exe" is on my path; "start firefox" does open a new window.

I'm trying to use the -search command line option. (https://developer.mozilla.org/en-US/docs/Mozilla/Command_Line_Options#-search_term)
In my command prompt I type:
start firefox.exe -search "my term"
start firefox -search "my term"
firefox -search "my term"
firefox.exe -search "my term"

Actual results:

In all cases I've outlined above, a new window simply opens without searching using my default search engine. This is mildly frustrating due to it being an integral part of my work flow.

Expected results:

Following issuing:
start firefox -search "my term"
A new browser should have opened and have searched using my default search engine (Google) the term "my term".

Component: Untriaged → Startup and Profile System
Product: Firefox → Toolkit

This looks like an issue with the search service.

_ensureInitialized@resource://gre/modules/SearchService.jsm:569:15
get defaultEngine@resource://gre/modules/SearchService.jsm:2116:10
doSearch@resource:///modules/BrowserContentHandler.jsm:312:16
bch_handle@resource:///modules/BrowserContentHandler.jsm:456:7

JavaScript error: resource:///modules/BrowserContentHandler.jsm, line 312: NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "Something tried to use the search service before it's been properly intialized. Please examine the stack trace to figure out what and where to fix it:
_ensureInitialized@resource://gre/modules/SearchService.jsm:569:15
get defaultEngine@resource://gre/modules/SearchService.jsm:2116:10
doSearch@resource:///modules/BrowserContentHandler.jsm:312:16
bch_handle@resource:///modules/BrowserContentHandler.jsm:456:7
" {file: "resource://gre/modules/SearchService.jsm" line: 569}]'[JavaScript Error: "Something tried to use the search service before it's been properly intialized. Please examine the stack trace to figure out what and where to fix it:   _ensureInitialized@resource://gre/modules/SearchService.jsm:569:15
get defaultEngine@resource://gre/modules/SearchService.jsm:2116:10
doSearch@resource:///modules/BrowserContentHandler.jsm:312:16
bch_handle@resource:///modules/BrowserContentHandler.jsm:456:7
" {file: "resource://gre/modules/SearchService.jsm" line: 569}]' when calling method: [nsISearchService::defaultEngine]```
Component: Startup and Profile System → Search
Product: Toolkit → Firefox

I can reproduce this.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mdeboer)
Flags: needinfo?(dharvey)
Keywords: regression
Assignee: nobody → mdeboer
Status: NEW → ASSIGNED
Iteration: --- → 69.3 - Jun 10 - 23
Points: --- → 2
Flags: needinfo?(mdeboer)
Priority: -- → P1
Assignee: mdeboer → dharvey
Flags: needinfo?(dharvey)

Been debugging this, if we introduce anything async between BrowserContentHandler.handle() and the resulting openBrowserWindow() call then the call to openBrowserWindow() fails, this means we cant await Services.search.init(), (the init call succeeds though)

...in which case it might be an idea to skip the defaultEngine lookup (do the argument parsing part), wait for the window to be opened and load the search in the first blank tab that's being opened, right?

Attachment #9075700 - Attachment description: Bug 1559625 - Let popup display out of the permissions popup. → Bug 1559625 - Let menupopup display out of the permissions popup.
Attachment #9075700 - Attachment description: Bug 1559625 - Let menupopup display out of the permissions popup. → Bug 1559625 - Let popup display out of the permissions popup.
Pushed by dharvey@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/66be066c4ac0
Let popup display out of the permissions popup. r=Gijs

Argh I did a bad copy and paste and put the wrong bug number on that, getting it backed out and will reland with the correct message

Backout by nbeleuzu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1f3c435c7b8b
Backed out changeset 66be066c4ac0 for wrong bug number. CLOSED TREE
Attachment #9075700 - Attachment description: Bug 1559625 - Let popup display out of the permissions popup. → Bug 1561266 - Let popup display out of the permissions popup.

Comment on attachment 9075700 [details]
Bug 1561266 - Let popup display out of the permissions popup.

Revision D36784 was moved to bug 1561266. Setting attachment 9075700 [details] to obsolete.

Attachment #9075700 - Attachment is obsolete: true
Attachment #9074473 - Attachment description: Bug 1559625 - Let SearchService init when called via -search. r?mikedeboer → Bug 1559625 - Let SearchService init when called via -search.
Pushed by dharvey@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c551aa1ed813
Let SearchService init when called via -search. r=mikedeboer
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 70

Hi Mike, can we please get an uplift request for this for 69 and ESR68? Thanks!

Flags: needinfo?(mdeboer)

Comment on attachment 9074473 [details]
Bug 1559625 - Let SearchService init when called via -search.

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Visible feature regression
  • User impact if declined: User wont be able to start with -search command
  • Fix Landed on Version: 67
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The code changed only touches the startup path, unlikely to regress anything and manually verified (not easy to test)
  • String or UUID changes made by this patch:

Beta/Release Uplift Approval Request

  • User impact if declined: User wont be able to start with -search command
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Start firefox with firefox -search test, page should open with default search engines entered the query "test"
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The code changed only touches the startup path, unlikely to regress anything and manually verified (not easy to test)
  • String changes made/needed:
Attachment #9074473 - Flags: approval-mozilla-esr68?
Attachment #9074473 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Flags: needinfo?(mdeboer)

Comment on attachment 9074473 [details]
Bug 1559625 - Let SearchService init when called via -search.

Fixes a regression with the -search command line flag. Baked on Nightly without any new issues reported. Approved for 69.0b11 and 68.1esr.

Attachment #9074473 - Flags: approval-mozilla-esr68?
Attachment #9074473 - Flags: approval-mozilla-esr68+
Attachment #9074473 - Flags: approval-mozilla-beta?
Attachment #9074473 - Flags: approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0
Build ID: 20190804214813

Verified as fixed on the latest Nightly 70.0a1 on Windows 10x64.

Verified as fixed also on the latest Firefox 69 beta 11 and on Firefox 68.1.0 esr. (tested on Windows 10x64)

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