1559625 - -search command line option not functioning in Windows

Status: VERIFIED FIXED

(Firefox :: Search, defect, P1)

Description

[ben.m.weller]

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".

Comment 1

[Dave Townsend [:mossop]]

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]```

Comment 2

[Mark Banner (:standard8)]

I can reproduce this.

Comment 3

[Dale Harvey (:daleharvey)]

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)

Comment 4

[Mike de Boer [:mikedeboer]]

...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?

Comment 5

[Dale Harvey (:daleharvey)]

Attachment: Bug 1559625 - Let SearchService init when called via -search.

Comment 6

[Dale Harvey (:daleharvey)]

Attachment: Bug 1561266 - Let popup display out of the permissions popup.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/66be066c4ac0
Let popup display out of the permissions popup. r=Gijs

Comment 8

[Dale Harvey (:daleharvey)]

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

Comment 9

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1f3c435c7b8b
Backed out changeset 66be066c4ac0 for wrong bug number. CLOSED TREE

Comment 10

[Phabricator Automation]

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.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c551aa1ed813
Let SearchService init when called via -search. r=mikedeboer

Comment 12

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/c551aa1ed813

Comment 13

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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

Comment 14

[Dale Harvey (:daleharvey)]

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:

Comment 15

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 16

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-esr68/rev/46be01314678

Comment 17

[Oana Pop-Rus]

https://hg.mozilla.org/releases/mozilla-beta/rev/8510b616a4b4

Comment 18

[Simona Badau, Desktop QA]

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.

Comment 19

[Simona Badau, Desktop QA]

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

Comment 20

[ben.m.weller]

Hate to bring up an old issue here, how did you do your testing?

I'm still running in to this issue on 70.0.1.

When I have my default profile open, and I try and run any of the commands that I have outlined in my initial bug report I still just get new instances of Firefox that haven't searched using my default search engine.

Comment 21

[Mark Banner (:standard8)]

(In reply to ben.m.weller from comment #20)

Hate to bring up an old issue here, how did you do your testing?

I would have followed comment 0.

When I have my default profile open, and I try and run any of the commands that I have outlined in my initial bug report I still just get new instances of Firefox that haven't searched using my default search engine.

Do you mean new instances, as in different profiles, or new windows? If you mean new windows, that's expected functionality at the moment, and that's what has been tested here.