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

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[cacaoso]

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,
e.g. 
CD "C:\Program Files\Mozilla Firefox"
START firefox.exe -P profile1name -no-remote
START firefox.exe -P profile2name -no-remote
...etc



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

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

[Loic]

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

[cacaoso]

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

[Loic]

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
PAUSE
START firefox.exe -P "batch3" -no-remote
EXIT
--------------------------------------------

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:

m-c
good=2012-04-29
bad=2012-04-30
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8f377102841b&tochange=cfaf90b22fc3

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.

Comment 4

[cacaoso]

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

[cacaoso]

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

Comment 6

[axel.bender]

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.

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 8

[Lee_Dailey]

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
http://forums.mozillazine.org/viewtopic.php?f=38&t=2541425&p=12277469#p12277469

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

take care,
lee

Comment 9

[Lee_Dailey]

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,
lee

Comment 10

[axel.bender]

> 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

[Bruno G.]

For those affected by this bug, there is a workaround : http://support.mozilla.org/en-US/questions/935967

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

[Lee_Dailey]

howdy [e-mail],

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,
lee

Comment 15

[Glenn Linderman]

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

[Alexandre Poirot [:ochameau]]

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

[Alexandre Poirot [:ochameau]]

Attachment: Implement bug 673383 into a new command line argument: /attach-console

Comment 18

[Glenn Linderman]

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

[Alexandre Poirot [:ochameau]]

Attachment: 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

[Glenn Linderman]

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

Comment 21

[Alexandre Poirot [:ochameau]]

Attachment: Hotfix addon

Same addon, but compatible with any mozilla application based on 15 platform version. So that it should work with thunderbird, seamonkey, xulrunner, ...

Comment 22

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 23

[Lukas Blakk [:lsblakk] use ?needinfo]

Sumo forum post: https://support.mozilla.org/en-US/forums/contributors/708644

Comment 24

[Glenn Linderman]

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.

Comment 25

[Alex Keybl [:akeybl]]

Given the hotfix workaround, no need to track for release.

Comment 26

[Glenn Linderman]

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.

Comment 27

[Dave Townsend [:mossop]]

(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 28

[(not currently active) Ted Mielczarek]

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.

Comment 29

[Ryan VanderMeulen [:RyanVM]]

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.

https://tbpl.mozilla.org/?tree=Try&rev=de4b3b31df98

Comment 30

[Ryan VanderMeulen [:RyanVM]]

(In reply to Ryan VanderMeulen from comment #29)
> https://tbpl.mozilla.org/?tree=Try&rev=de4b3b31df98

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?

https://hg.mozilla.org/integration/mozilla-inbound/rev/e9f40f834e8d

Comment 31

[Ryan VanderMeulen [:RyanVM]]

Attachment: Add back the code that was reverted

Comment 32

[Ryan VanderMeulen [:RyanVM]]

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

[Alexandre Poirot [:ochameau]]

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.

Comment 34

[Mounir Lamouri (:mounir)]

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

Comment 35

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e4be135eff48

Comment 36

[Ed Morley [:emorley]]

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

Comment 39

[Robert Schaffrath]

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

Comment 41

[Loic]

Firefox 17 ESR is affected by this bug, as reported in the bug I duped.