1569089 - The "-version" ("-v") command line option doesn't report version information when using cmd.exe

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect, P3)

Description

[YUKI "Piro" Hiroshi]

Firefox supported a command line option "-version" (or "-v") to print its version, like:

> "c:\Program Files\Mozilla Firefox ESR60\firefox.exe" -version | more
Mozilla Firefox 60.7.2


> 

However the option looks unavailable on recent versions.

Steps to reproduce

1. Install Nightly on Windows.
2. Open cmd.exe.
3. Type "c:\Program Files\Mozilla Nightly\firefox.exe" -version | more and run it.

Actual result

Just line breaks are printed and there is no version information, like:

> "c:\Program Files\Mozilla Nightly\firefox.exe" -version | more


> 

Expected result

A valid version information is printed like:

> "c:\Program Files\Mozilla Nightly\firefox.exe" -version | more
Mozilla Firefox 70.0a1


> 

Envrionment

• Windows 10 1809 Pro
• Firefox 67.0.1 (64bit)
• Firefox ESR68.0 (64bit)
• Nightly 70.0a1 (64bit) build ID: 20190725215157

Comment 1

[YUKI "Piro" Hiroshi]

I've confirmed that the option works with Firefox ESR60. Because mozregression is not usable for this case, the initial failure build is not determined yet.

Comment 2

[YUKI "Piro" Hiroshi]

https://dxr.mozilla.org/mozilla-esr60/source/toolkit/xre/nsAppRunner.cpp#3525
https://searchfox.org/mozilla-central/rev/40e889be8ff926e32f7567957f4c316f14f6fbef/toolkit/xre/nsAppRunner.cpp#3480

The option is still defined on Nightly, so it looks a problem of DumpVersion() or something related to the standard output.

Comment 3

[YUKI "Piro" Hiroshi]

I successfully got the expected output on the Windows PowerShell. On my environment this works as expected:

PS C:\Users\user> & 'C:\Program Files\Mozilla Firefox\firefox.exe' '-version' | more
Mozilla Firefox 68.0.1

So this looks a problem appearing only on the cmd.exe.

Comment 4

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

The priority flag is not set for this bug.
:Dolske, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Cristian Fogel [:cfogel]]

Confirmed issue with 70.0a1 (2019-08-13) on Windows 10.
Hope this helps:

• Last good: buildID 20190329153554
  pushlog link
• First bad: buildID 20190330093331

Comment 6

[Dão Gottwald [:dao]]

(In reply to Cristian Fogel, QA [:cfogel] from comment #5)

Confirmed issue with 70.0a1 (2019-08-13) on Windows 10.
Hope this helps:

• Last good: buildID 20190329153554
  pushlog link
• First bad: buildID 20190330093331

Changes in that range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=69e9ee0ef3dd97a412d90be9c8377d660d08cbc2&tochange=5f519306c8bdf77c3236abcb626eacfe44c5e1f0

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

Dão, or dolske, can you help find someone to work on this, maybe for the 71/72 release? Thanks!
For a simple enough fix, I would still take a patch for 70 beta 13 or 14, tbh, because of how much I love Tree Style Tab ;)

Comment 8

[Dão Gottwald [:dao]]

Sorry, I don't manage engineers. It would be helpful to pin down what bug caused this but nothing jumps out at me from the regression range.

Comment 9

[Mark Banner (:standard8)]

Command line handling is handled in the code relating to Startup & Profile system, so lets move this across there and see if the triage owners can help.

Comment 10

[Dave Townsend [:mossop]]

Bug 1528963 looks suspicious

Comment 11

[Masatoshi Kimura [:emk]]

Attachment: Bug 1569089 - Sync std handles after AttachConsole(). r?aklotz

AttachConsole() may change Win32 std handle values if Firefox is launched from
cmd.exe that makes discrepancy between Win32 and CRT. This patch synchronizes
both std handles.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ded1972eb688
Sync std handles after AttachConsole(). r=aklotz

Comment 13

[Cosmin Sabou [:CosminS]]

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

Comment 14

[Cristian Fogel [:cfogel]]

Fix verified for 72.0a1 (2019-11-14) on Windows 10.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Unless someone can point to a real-world instance where this bug is causing problems in the wild, I'm inclined to just let this fix ride the trains.

Comment 16

[Masatoshi Kimura [:emk]]

Piro-san, do you want to uplift this to ESR68?

Comment 17

[YUKI "Piro" Hiroshi]

Initially this was reported by my customer who used it. This was actually a usecase in the wild. But they already migrated to something different way (maybe application.ini or the registry of Windows), so it looks not immediately-necessary.