366009 - When I specify a local file on the command line, Firefox launches with two windows

Status: RESOLVED FIXED

(Core Graveyard :: Cmd-line Features, defect)

Description

[Jesse Ruderman]

Steps to reproduce:
1. While Firefox isn't running, run

~/trunk/mozilla/fx-opt-static-gcc401-cc/dist/Minefield.app/Contents/MacOS/firefox-bin /Users/admin/Desktop/delta/lith/000539.xhtml

Result: Two windows appear, both showing 000539.xhtml.

Expected: Only one window should appear.

This happens with both "firefox" and "firefox-bin".

I'm marking this regression as "major" because it interferes with automated testing and automated testcase reduction.

Comment 1

[Jesse Ruderman]

Workaround: prefix the absolute path with "file://", making it a file: URL.

Comment 2

[(not currently active) Ted Mielczarek]

Maybe the same bug as bug 377097 ?  (not that that helps)

Comment 3

[Colin Barrett [:cbarrett]]

I had an interesting idea about this earlier so I decided to test it, and found interesting results. Typing this at the shell:

$ /Applications/TextEdit.app/Contents/MacOS/TextEdit ~/Documents/test.html

Opens TextEdit with test.html showing. 

$ /Applications/TextEdit.app/Contents/MacOS/TextEdit foo ~/Documents/test.html

Attempts to open a file called "foo", which TextEdit complains doesn't exist, and then opens test.html.

$ /Applications/TextEdit.app/Contents/MacOS/TextEdit -foo ~/Documents/test.html

Just opens test.html.

There may be code in Apple's NSApplicationMain that tries to parse paths passed to an application and then generate the appropriate Apple Event for opening that document. I'd guess this is what's causing both bug 377097 and this.

There might be some way to disable this, or perhaps we need to be removing args from the arg string before calling NSApplicationMain.

Comment 4

[Colin Barrett [:cbarrett]]

Okay, we don't seem to call NSApplicationMain, so there goes that theory.

Comment 5

[Colin Barrett [:cbarrett]]

Here's what I've been able to find out:

I looked at backtraces for window open events. They're the same trace, which rules out some weird code there. I've been trying to trace through elsewhere, but have been frustrated by gdb.

Through logging, I know that the NSApplication delegate method -application:openFile: is only called *once* when this bug occurs, and when I trigger bug 377097, -application:openFile: is also being called then, which suggests to me that the call to that delegate method is being generated erroneously. gdb refuses to break in that method, however.

I'll come back to this another time, hopefully I can get gdb to cooperate then. I've tried tracing at a number of other points and I'm not getting anything useful. Any gdb help would be appreciated. I've tried |b -[MacApplicationDelegate application:openFile:]| and |b MacApplicationDelegate.mm:115|, neither of which actually were hit.

Comment 7

[Benjamin Smedberg]

When you launch FF with a commandline param like that it is handled through the standard argv launching mechansim. If appleevents are *also* being fired for that parameter that's kinda bad.

It would be useful to add some logging to nsICommandLine/CommandLineHandler and/or nsBrowserContentHandler.js to see if we're getting multiple commandlines being dispatched.

Comment 8

[Benjamin Smedberg]

I can't block on this without more information. Can somebody do some commandline logging and figure out what is actually getting dispatched?

Comment 9

[Colin Barrett [:cbarrett]]

Hopefully soon? Although I welcome anyone to beat me to the punch.

Comment 10

[Colin Barrett [:cbarrett]]

Awesome, found a workaround. Do this:

[[NSUserDefaults standardUserDefaults] setObject:@"NO" forKey:@"NSTreatUnknownArgumentsAsOpen"];

sometime before we call -[NSApplication run]. Thanks to whoever made otx - http://otx.osxninja.com/ . Made my life 100x easier.

Comment 11

[Colin Barrett [:cbarrett]]

Attachment: proposed fix (1.0)

Here's my proposed fix. This is as good a place as any to put this, I think.

Comment 12

[Jesse Ruderman]

The patch fixes the bug for me :)

Comment 13

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 280033 [details] [diff] [review]
proposed fix (1.0)

This looks fine to me (though I haven't tested it).

The timing is fine, because SetupMacApplicationDelegate() is called
before appStartup->Run() (which in turn calls nsAppShell::Run(), which
in turn calls [NSApp run]).

One small nit -- application isn't spelled with 3 "p"s :-)

Camino (which doesn't use toolkit/xre/nsAppRunner.cpp's XRE_main() or
anything in MacApplicationDelegate.mm) won't be effected by this
change.  But that doesn't matter, because (for some reason) Camino
doesn't have this bug.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

By the way, Colin, good catch!

Comment 15

[Colin Barrett [:cbarrett]]

I'll fix the "ppp" issue on checkin. (there's also whitespace after @"NO", I've fixed that locally as well.)

Camino doesn't exhibit this bug because they don't do any parsing of command line arguments on their own.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 280033 [details] [diff] [review]
proposed fix (1.0)

a=bzbarsky

Comment 17

[Colin Barrett [:cbarrett]]

Checking in toolkit/xre/MacApplicationDelegate.mm;
/cvsroot/mozilla/toolkit/xre/MacApplicationDelegate.mm,v  <--  MacApplicationDelegate.mm
new revision: 1.7; previous revision: 1.6
done