472891 - "already open" error when launching SeaMonkey Editor using -edit or -remote cmd line options

Status: RESOLVED INCOMPLETE

(Core Graveyard :: X-remote, defect)

Description

[Steve McMillen]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090109 Shiretoko/3.1b3pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090109 Shiretoko/3.1b3pre

I'm trying to launch SeaMonkey html editor to a specific document on Mac os.  Basically I want to add a "open with" option so I can use SeaMonkey composer to edit html documents (I find it to be the perfect WYSIWYG HTML editor for simple business html authoring needs)

On Mac OS X, both Firefox and SeaMonkey do not allow for launching the app via cmd line as they do on Linux and Windows.

basically, I want to do something like this:
"<path>/seamonkey.exe" -edit "<path+filename>" 
or this:
"<path>/seamonkey.exe" -remote "openurl(http://www.mozilla.org)"

When trying this in SeaMonkey,In both cases, I get a message saying:
 "A copy of SeaMonkey is already open.  Only one copy of SeaMonkey 
  can be open at a time." 

I tried the -remote command in Firefox to.  I get the same message for Firefox.

On Linux, I was able to execute either command successfully (the -edit seems to work just like -remote should)

Note: I've already tried NVU.  Its horribly slow on Mac and not keeping up with the newer composer features (e.g. supporting <p> correctly).


Reproducible: Always

Steps to Reproduce:
1. Open SeaMonkey as normal
2. open a command prompt and type either of the following:
"<path>/SeaMonkey.app/Contents/MacOS/seamonkey-bin" -edit "<path+filename>" 
"<path>/SeaMonkey.app/Contents/MacOS/seamonkey-bin" -remote "openurl(http://www.mozilla.org)"


Actual Results:  
Get a dialog saying:
 "A copy of SeaMonkey is already open.  Only one copy of SeaMonkey can
be open at a time." 

Expected Results:  
In the first case, SeaMonkey opens the requested document for editing in Composer.
In the 2nd case, SeaMonkey opens the requested document for viewing in the browser.

On Linux and windows, SeaMonkey behaves as expected.  The document is opened per Expected results above.  So I think this is a bug with Mac OS X.

I looked for similar bugs but can't find one. 

Since Firefox/SeaMonkey only allow for one profile open a time on a box, it seems like the default behavior should always be top open the document in the current running profile unless the -p option is specified on the cmd line.

Comment 1

[Serge Gautherie (:sgautherie)]

Which SeaMonkey version are you using ?

Comment 2

[Steve McMillen]

Using 2.0a2 (Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081202 SeaMonkey/2.0a2)

Comment 3

[Tony Mechelynck [:tonymec]]

Moving to Core::X-remote though I hesitate between that and ::Command-line features.

Comment 4

[Nomis101]

I have exactly the same problem with Thunderbird on Mac OS X. If I try to add an attachment to an compose window with

/Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin -remote "xfeDoCommand(composeMessage,attachment='file:///example.psd')"

then I get the "A copy of Thunderbird is already open. Only one copy of Thunderbird 
  can be open at a time." message if Thunderbird is open. If Thunderbird is closed, than it works perfect.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090128 Shredder/3.0b2pre
and
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.2a1pre) Gecko/20090127 Thunderbird/3.1a1pre

Comment 5

[mozillabugzilla]

Confirmed problem with Thunderbird. This makes it impossible to script Thunderbird as a replacement for Mail.app

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1

Comment 6

[Joachim Kock]

This bug seems to be common to all mozilla apps on OSX:
the -remote flag has no effect: instead of connecting to an
already existing process, a new process is spawned, and it
immediately leads to the error message reported.

This bug effectively prevents any scripting of mozilla apps in
OSX -- since mozilla apps like Firefox and Thunderbird are
basic tools they tend to be always open, and therefore cannot
be scripted without the -remote flag.

I would also like to question the classification of this bug
into Core::X-remote.  It has nothing to do with the X-windowing
system.  I suggest that ::Command-line features is the correct
category.

Furthermore I would like to point out that it is not the
functionality per se that is broken but only to the command-line
interface to it.  This can be seen by the fact that if in a
Firefox web browser window you click on a mailto link, then
the already-running Thunderbird comes to front with a new-message
window correctly containing the email address clicked on.
Hence Firefox knows how to connect to an existing Thunderbird
process.  It is only the command line that does not.

(For the sake of completion, I mention that I observe this bug
with Firefox 2.0.0.14 and with Thunderbird 3.0b1 as well as 2.0.0.18
and 2.0.0.19.)

Cheers,
Joachim.

Comment 7

[Tony Mechelynck [:tonymec]]

I thought X-remote was whatever the -remote functionality uses, whether on X11 or on other platforms.

When I moved this to X-remote I said I hesitated between that and cmd-line. If someone wants to move this to cmd-line (and maybe assign it to himself and solve it there), why not?

Adding a whiteboard remark to mention that the bug already existed in Gecko 1.8.1.x (i.e., Fx/Tb 2.0.0.x)

Confirming because of concording reports by several witnesses.

Comment 8

[Nomis101]

(In reply to comment #6)
> Furthermore I would like to point out that it is not the
> functionality per se that is broken but only to the command-line
> interface to it.  
Because you mentioned the command-line, I was hoping Bug 380163 can also fix this bug. And so I build a Thunderbird with the patch from Bug 380163. But this doesn't fix the remote issue. But maybe the remote issue can be fixed similar to the work in Bug 380163?

Comment 9

[Dominik Wnęk]

I just ran into this bug. I am using the iPhoto Thunderbird Bridge script (http://softpixel.com/~cwright/programming/iPhoto/), trying to export photos directly from iPhoto. Had to modify the script slightly, because for some reason it includes a "-p iPhoto" switch, which causes the select profile box to appear on startup (I have no iPhoto profile) - even though Thunderbird's command-line help suggests the option should be an upper case P.

Symptoms are exactly as described above, with the exception that when I add -remote to the command and Thunderbird isn't running, it starts and then immediately closes. Thunderbird is version 2.0.0.21.

Also, shouldn't this bug be marked as confirmed?

I'm hoping this can be fixed soon :-)

Comment 10

[Ari Maniatis]

Although this task doesn't have many votes, I think it is very important. Solving this problem would go a long way to work around the lack of Applescript support in Thunderbird, because we would then be able to write Applescript which executed the command line to create new emails in Thunderbird. On OSX this means:

* tying iPhoto email sending into TB
* 'email PDF' from standard print dialogs would work
* third party programs can create emails in TB just like they do in Apple Mail (there are lots and lots which do this).

I can confirm this bug, if that helps us getting it into status CONFIRMED.

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Bug 287345 comment 9 describes the (Mac OS X-only) source of the inability to add files to Tb when it's already running.  

This might be the bug that should implement part of the fixes for the issues in bug 287345 comment 9; regardless, it should live somewhere not Linux-specific :P

Comment 12

[u93378]

I was trying to use -remote to connect to Thunderbird from emacs org-mode.  Very disappointed that this doesn't work. :-(

Comment 13

[Pavel Volkovitskiy]

Still doesn't work with Firefox 28.0 and Thunderbird 24.4.0 on MacOSX 10.9.2

Comment 14

[Benjamin Smedberg]

Mass resolving a bunch of old bugs in the x-remote component in preparation for archiving it. If this bug is still valid and useful, please move it to the "Toolkit: Startup and Profile System" component and reopen it.