Launching Firefox 15 from DOS command prompt/batch file closing problem

RESOLVED FIXED in mozilla18



Startup and Profile System
6 years ago
a year ago


(Reporter: cacaoso, Assigned: ochameau)


(Depends on: 1 bug, {dev-doc-needed, regression})

15 Branch
Windows XP
dev-doc-needed, regression
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(firefox15-, firefox16- affected, firefox17- affected, firefox18-)



(3 attachments, 1 obsolete attachment)



6 years ago
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20100101 Firefox/15.0
Build ID: 20120824154833

Steps to reproduce:

I usually launch a few firefox profiles from a batch file,
CD "C:\Program Files\Mozilla Firefox"
START firefox.exe -P profile1name -no-remote
START firefox.exe -P profile2name -no-remote

Actual results:

Now launching is fine, no problems there. Its at the end of the batch file the DOS command prompt window supposed to close but it kinda stays there after the last line is executed.

But if I were to click and close the DOS command prompt window, all my firefox windows (profiles) will close with it. I only observed this when I updated to v15 this morning. Yesterday (v14.0.1) was fine.

Also if I were to just go to Start>Run>cmd and type 
CD "C:\Program Files\Mozilla Firefox"

My default profile will launch. 
At the DOS Command Prompt if I type > exit --> the command prompt windows still stay there (I cannot type anymore in there) but doesn't close. If I were to click close the default profile firefox will close with it.

Btw tried this on another computer with same version of firefox same problem. Tried it on yet another computer running v14.0.1 and this problem does not exist.

Expected results:

Normally, the batch file opens the command prompt window, launches all the profile windows then closes itself, all firefox profiles remain open.

Based on the 2 above scenarios, could this be due the new memory leak fix method? I hope not I still want to be able to launch my profiles with a batch file as per normal.

Comment 1

6 years ago
I tried on Win 7 64 bits with this batch:

@echo off
CD "C:\Program Files (x86)\Mozilla Firefox\"
START firefox.exe -P "batch1" -no-remote
START firefox.exe -P "batch2" -no-remote
START firefox.exe -P "batch3" -no-remote

No issue here, each profile has been loaded and the MS-DOS prompt closed itself after running the script.

Comment 2

6 years ago
Ok when I added the "" around the profile name the whole batch file will go thru.

But try this:
@echo off
CD "C:\Program Files (x86)\Mozilla Firefox\"
START firefox.exe -P "batch1" -no-remote
START firefox.exe -P "batch2" -no-remote
pause                                           <--- put a pause here
START firefox.exe -P "batch3" -no-remote

When the command prompt is open and paused at that spot, try closing the command prompt it should close the batch1 and batch2 profiles with it, which does not happen with versions before v15.

I would seem that firefox is not somehow tied to the command prompt like its parent process. Once that closes everything spawned from it closes as well.

Comment 3

6 years ago
Now your STR are clear. :)

The batch file I used is:
@echo off
CD "C:\Program Files (x86)\Mozilla Firefox\"
START firefox.exe -P "batch1" -no-remote
START firefox.exe -P "batch2" -no-remote
START firefox.exe -P "batch3" -no-remote

I made several several observation:

1) If I close the DOS console during the pause, both Firefox processes running "batch1" and "batch2" are closed at the same time.

2) If I press on a key during the pause, "batch3" is open too but the DOS prompt stays open despite the EXIT command. When I close the prompt, "batch1" and "batch2" are closed too.

3) When I close all the 3 Firefox processes, the EXIT command works and the DOS prompt closes itself.

It looks like now the child processes need to be closed in order to close the parent process itself.

I tried mozregression and I found a regression range:


Suspected bug:
Alexandre Poirot — Bug 673383 - Output stdout in regular command line on Windows. r=ted 

Anyway I'm not sure it's a real regression, maybe it's the intended behavior now.
Blocks: 673383
Component: Untriaged → Startup and Profile System
Keywords: regression
Product: Firefox → Toolkit
Summary: Launching firefox from DOS command prompt/batch file closing problem → Launching Firefox 15 from DOS command prompt/batch file closing problem

Comment 4

6 years ago
Ok, I'll pretend I understood that :) Its probably a side effect of the technique they used to tackle the memory leak issue. I hope they managed to fix that problem. The culprit now seems to be the pause command. If my batch file does not have a pause command anywhere along the way it will close properly.

Maybe we can try some other way of pausing? Like a choice command? I think there is one?

Comment 5

6 years ago
Hi v15.0.1 This bug/feature is still there. Any news as to whether this is abnormal behavior?


6 years ago
tracking-firefox15: --- → ?
tracking-firefox16: --- → ?
tracking-firefox17: --- → ?
tracking-firefox18: --- → ?
Ever confirmed: true

Comment 6

6 years ago
After the update to FF 15.x (or Thunderbird 15.x for that matter) the following issues are evident when starting FF from the command line (cmd.exe) on Windows Server 2003 32 bit or Windows 7 64 bit:

1) FF's stderr is echoed to the command line interfering with the output of standard commands like "dir"

2) A Ctrl-C in the command line (cmd.exe) kills FF at once; the same happens if the command line is closed via e.g. "exit".

This behavior is very odd, and - to me - seems to fulfill no purpose.
Definitely not tracking/chemspilling another 15 release for this considering it is likely not a widely used method of launching firefox.  Let's find out from Alexandre if this is in fact a regression or the intended behaviour before making a call on tracking a backout or forward fix here. We're a week away from our last Beta where we'd take a speculative fix but a backout can be done any time in the coming 3 weeks if that's the call made.
tracking-firefox15: ? → -
Assignee: nobody → poirot.alex

Comment 8

6 years ago
howdy y'all,

i'm having this problem also - with both ff15 and tb15. plus i have a somewhat simpler STR.

os = win7x32
ff = 15.0.1
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0.1
tb = 15.0
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120824 Thunderbird/15.0

STR [Steps To Reproduce]
1- create a script file
either BAT or CMD will do.
2- put the command line to start your mozilla app [either ff or tb] in the file
as an example, in windows explorer ...
--- navigate to the folder containing the firefox.exe file
--- shift-right-click on the firefox.exe file
--- select "copy as path" from the context menu
--- paste the result into your script file
3- do NOT add anything more than an optional <enter> to end the line
your file should be only one or two lines. one with the EXE and an optional blank one after that line.
for instance, i ended up with this [note the trailing blank line] ...
\start code
"C:\Program Files\Mozilla Firefox\firefox.exe"

\end code

4- save the file to some convenient folder [perhaps one on your PATH statement]
5- run the script

the script runs and the app opens, but there are several problems ...
[a] the script does not exit, it remains open.
[b] in the script window, on the line immediately after the EXE you will see the word "cache!".
[c] if you close the script, the app closes.

link to the mozillazine forum thread ...
- problem with CMD & BAT files since v-15 of ff & tb • mozillaZine Forums

this completely blows away my workflow. [*sigh ...*] 

take care,

Comment 9

6 years ago
howdy y'all,

lordy! i left out a step! [*blush*] 

this ONLY happens if ...
- the CMD file above is called from another CMD file
- the CMD file above is called from an open command window
- the CMD file contains anything other than another "start filename.exe" after the firefox or thunderbird line [such as a PAUSE statement]

sorry for the inaccurate STR above. [*sigh ...*] 

take care,

Comment 10

6 years ago
> Lukas Blakk [:lsblakk] 2012-09-10 15:12:07 PDT

> Definitely not tracking/chemspilling another 15 release for this considering it is likely not > a widely used method of launching firefox. 

What are you refering to? Calling FF from the command line or from a batch? That's ridiculous!
Instead of creating a new version every then and now you (this is not personal!) should check your builds before releasing them, and not assume (or try to define for that matter) how we - the users - should use FF.

I use FF ONLY like this, and - that said - this change ruins my workflow.

Sorry this had to be said - no offense intended.

Comment 11

6 years ago
For those affected by this bug, there is a workaround :

In short, use this command in your batch file :
start "TempShell" /D "C:\Program Files\Mozilla Firefox" /B "CMD /C start ""Firefox"" firefox.exe"

Thunderbird as well...

Comment 12

6 years ago

that works perfectly! thank you _very_ much. i hope the devs can figure out what they did, but i am back working smoothly.

take care,


6 years ago
Whiteboard: workaround in comment 11
Duplicate of this bug: 790179
Duplicate of this bug: 790050

Comment 15

6 years ago
790050 is a duplicate of this bug, so no problem marking it dup, but unless the developers already have a handle on the cause, 790050 describes more clearly that it is an interaction with the console window, not the CMD or batch file; that the problem is caused if the console window used to launch firefox has ever had a read request... pause is only an example of that, other types of read request (reading the firefox command from the console is another example).

I look forward to trying out the workaround mentioned, but this is, clearly, a regression, because it is not mentioned in the what's new list of features, and it is a change... and a very weird behavior at that.  The workaround likely works because it causes the creation of a new console window from which firefox can be launched, and that console window doesn't have and read requests invoked on it. Looks like I'll need to rework a fair number of batch files to avoid this bug.

Comment 16

6 years ago
That's a regression from bug 673383. We missed that issue until FF15 reached release channel.

For some reason the call to AttachConsole introduced in bug 673383 link Firefox process to the console. This call was introduced in order to be able to see Firefox stdout directly from the console by using: cmd /C firefox.exe 
So that you do not need to pass /console and have this temporary console window. And it ends up being way easier to fetch firefox stdout when running it from another program.

Given the number of reports and the difficulty to address all Windows console corner cases, I'd suggest to move the code introduced in bug 673383 into yet another flag.

I'm currently building a patch to do that.

Comment 17

6 years ago
Created attachment 660092 [details] [diff] [review]
Implement bug 673383 into a new command line argument: /attach-console
Attachment #660092 - Flags: review?(ted.mielczarek)

Comment 18

6 years ago
Glad to know the root cause is well understood, even if the Windows console isn't well understood (no blame here, it is bizarre in quite a few respects).

Is this likely to be fixed soon in a 15.0.2, so that I can just put up with the problem a few more days, or should I go tweak all my batch files with the workaround?

Comment 19

6 years ago
Created attachment 660206 [details]
Hotfix addon

It is up to Lukas to push this fix to an eventual new 15.x version.
But in the meantime, you can use this addon hotfix. I gave it a try and it seems to work fine.

Comment 20

6 years ago
Yes it works. Is someone producing a similar fix and/or hotfix for Thunderbird?

Comment 21

6 years ago
Created attachment 660376 [details]
Hotfix addon

Same addon, but compatible with any mozilla application based on 15 platform version. So that it should work with thunderbird, seamonkey, xulrunner, ...
Attachment #660206 - Attachment is obsolete: true
Thanks for finding the workaround and putting up an addon hotfix. This does not warrant distribution for 15, we only deploy hotfixes in instances where there is a large population affected, but we'll reach out to our support team and document this properly for the duration of 15 and when the patch is reviewed please nominate for uplift to branches.
status-firefox16: --- → affected
status-firefox17: --- → affected
status-firefox18: --- → affected
tracking-firefox16: ? → +
tracking-firefox17: ? → +
tracking-firefox18: ? → +

Comment 24

6 years ago
I have verified the latest hotfix is compatible with Firefox and Thunderbird and resolves my problems completely. Only sticking point was realizing that, as the hotfix (I'd never encountered one before) is an addon, it has to be applied to each profile individually, rather than just being installed once per application. Hopefully the documentation will make that clear to affected users.
Given the hotfix workaround, no need to track for release.
tracking-firefox16: + → -
tracking-firefox17: + → -
tracking-firefox18: + → -

Comment 26

6 years ago
I don't understand all the policies... but why not track for release? Is the hotfix guaranteed to work with future releases? Even if it is, it is one more annoyance in deploying batch files that launch firefox (or thunderbird, etc.) to people that don't have the hotfix installed.
(In reply to Glenn Linderman from comment #26)
> I don't understand all the policies... but why not track for release? Is the
> hotfix guaranteed to work with future releases? Even if it is, it is one
> more annoyance in deploying batch files that launch firefox (or thunderbird,
> etc.) to people that don't have the hotfix installed.

It means we aren't tracking it for the releases that are currently undergoing stabilization, it will be fixed in a future version of Firefox, likely 18 if the current patch gets reviewed and landed in the next few weeks.
Comment on attachment 660092 [details] [diff] [review]
Implement bug 673383 into a new command line argument: /attach-console

Review of attachment 660092 [details] [diff] [review]:

This makes me sad, but I guess it's necessary. Tossing feedback? at bsmedberg to see if he has an opinion on the new command-line option.
Attachment #660092 - Flags: review?(ted.mielczarek)
Attachment #660092 - Flags: review+
Attachment #660092 - Flags: feedback?(benjamin)


6 years ago
Attachment #660092 - Flags: feedback?(benjamin) → feedback+


6 years ago
Attachment #660092 - Flags: checkin?
Keywords: checkin-needed
Attachment #660092 - Flags: checkin?
I don't see a Try run here, so I've pushed it to Try to be safe. I'll land it if it's green. Also note that I had to un-bitrot this a bit.
(In reply to Ryan VanderMeulen from comment #29)

Green on Try. Though I think I regressed bug 753856 in the process. Alexandre, is that correct? And if so, why was this patch created against code from 4 months ago instead of m-c?
Flags: in-testsuite-
Keywords: checkin-needed
Created attachment 664702 [details] [diff] [review]
Add back the code that was reverted
Attachment #664702 - Flags: review?(poirot.alex)
Whiteboard: workaround in comment 11 → [leave open]
Locally, I've also changed the comment a bit to fit 80 columns.
                // Merge stderr into CONOUT$ since there isn't any `CONERR$`.

Comment 33

6 years ago
Comment on attachment 664702 [details] [diff] [review]
Add back the code that was reverted

Oh sorry Ryan for this mess, thank you so much for catching that up!
You are totally right. I may either tried to build a patch against mozilla-release branch or mess with my hg commands.
Attachment #664702 - Flags: review?(poirot.alex) → review+
Keywords: checkin-needed
Whiteboard: [leave open]
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18


6 years ago
status-firefox18: affected → ---
Duplicate of this bug: 800260
Duplicate of this bug: 779422
Keywords: dev-doc-needed

Comment 39

6 years ago
The hotix continues to work fine with Firefox 16 and Thunderbird 16.


5 years ago
Duplicate of this bug: 840028

Comment 41

5 years ago
Firefox 17 ESR is affected by this bug, as reported in the bug I duped.
You need to log in before you can comment on or make changes to this bug.