Still present in F20 with claws-mail 3.9.3 +++ This bug was initially created as a clone of Bug #956380 +++ Description of problem: Clicking on a mailto link in Firefox when Claws Mail is already running brings up a second Claws Mail window along with the Compose Message window. Version-Release number of selected component (if applicable): claws-mail-3.9.0-1.fc18.x86_64 How reproducible: Happens every time Steps to Reproduce: 1. Start Claws Mail. 2. Start Firefox. 3. Direct Firefox to a page with a mailto link. 4. Click on the mailto link. Actual results: A new Claws Mail window appears along with a new Compose Message window. Expected results: A new Compose Message window should appear. Additional info: If I right-click on an email address in a Terminal and select the "Send Mail To..." option when Claws Mail is already running, a new Compose Message window comes up without a new Claws Mail window. --- Additional comment from Michael Schwendt on 2013-04-24 23:24:42 CEST --- Reproducible with claws-mail-3.9.0-9.cvs122.fc19.x86_64 A second process "claws-mail mailto:address-here" is started. --- Additional comment from Michael Schwendt on 2013-05-20 10:49:23 CEST --- Currently not reproducible anymore with claws-mail-3.9.1-1.fc19.x86_64 Only another Claws Mail compose window is opened. 2164 ? Sl 0:00 claws-mail first 2178 ? S 0:00 \_ claws-mail first 2179 ? Sl 0:00 | \_ emacs --no-splash /home/ms19a/.claws-mail/tmp/tmpmsg.0x16594e0 2194 ? S 0:00 \_ claws-mail first 2195 ? Sl 0:00 | \_ emacs --no-splash /home/ms19a/.claws-mail/tmp/tmpmsg.0xe92c00 2311 ? S 0:00 \_ claws-mail first 2312 ? Sl 0:00 \_ emacs --no-splash /home/ms19a/.claws-mail/tmp/tmpmsg.0x20f31a0 --- Additional comment from Michael Schwendt on 2013-05-22 20:41:39 CEST --- Seems to be a more generic issue specific to Firefox. Cannot say that Claws Mail 3.9.1 would fix it. --- Additional comment from Aram Agajanian on 2013-05-22 22:06:52 CEST --- I can no longer reproduce this bug on Fedora 18. I have tested with firefox releases 20.0-1 and 21.0-3. --- Additional comment from Michael Schwendt on 2013-05-22 22:14:46 CEST --- Okay, I've had a look. The /usr/bin/firefox shell script does something nasty: ## ## Use $MOZ_TMPDIR if set. Otherwise use /var/tmp instead of /tmp ## because of 1GB /tmp limit in Fedora 18 and later. ## See: https://bugzilla.redhat.com/show_bug.cgi?id=867073 ## TMPDIR="${MOZ_TMPDIR:-/var/tmp}" export TMPDIR Claws Mail on the other hand relies on g_get_tmp_dir(), which reads the env vars TMPDIR, TMP, TEMP (in that order), and if none is defined, defaults to /tmp. So, the tmp_dir path varies depending on whether Claws Mail is started from within Firefox or the desktop env (or shell). The firefox script ought to respect a user-defined $TMPDIR and not override it like this. I'll add a comment there. --- Additional comment from Aram Agajanian on 2013-05-22 22:42:38 CEST --- OK, now I can reproduce this bug on Fedora 18. [agajania@localhost tmp]$ ll /tmp/*claws* /var/tmp/*claws* srwxrwxr-x. 1 agajania agajania 0 May 22 16:36 /tmp/claws-mail-1000 srwxrwxr-x. 1 agajania agajania 0 May 22 16:36 /var/tmp/claws-mail-1000 --- Additional comment from Michael Schwendt on 2013-05-24 10:33:58 CEST --- I've posted about this also to Claws Mail users' list. Temporary work-around: Set TMPDIR and MOZ_TMPDIR environment variables to the same location. --- Additional comment from Michael Schwendt on 2013-07-08 19:45:11 CEST --- So, where are we now? Meanwhile, Fedora /usr/bin/firefox respects $TMPDIR if set. That's a work-around for users who know about this and do set $TMPDIR. That doesn't help us much with regard to this issue. If $TMPDIR is not set when Claws Mail is started, it will fall back to using /tmp (see comment 5). When launching Claws Mail from within Firefox, /var/tmp will be used instead. I don't feel like replacing g_get_tmp_dir() with something that would do the same as Fedora's /usr/bin/firefox shell script. What about a README.Fedora for mentioning this $TMPDIR detail? The least we could do, IMO. --- Additional comment from Michael Schwendt on 2013-07-21 20:18:36 CEST --- I've had a discussion yesterday about a similar problem and also about this particular issue then: https://fedoraproject.org/wiki/Staying_close_to_upstream_projects Basically, patching Claws Mail in Fedora would result in a significant deviation from upstream. Behaviour of Fedora's Claws Mail would differ from upstream. That would already be a problem when switching back and forth between Fedora packages and a snapshot from git. Also, Firefox only messes with $TMPDIR in Fedora. It doesn't do that in RHEL (yet). --- Additional comment from Fedora End Of Life on 2013-12-21 16:29:51 CET --- This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
A work-around is described here: http://lists.claws-mail.org/pipermail/users/2013-December/008000.html
Since you've found the work-around, which is also explained in the README.Fedora file included within the Fedora claws-mail package, how about applying that work-around in your ~/.bash_profile file? Nothing else can be done in Fedora claws-mail, if other applications mess with environment variables, such as TMPDIR. If to work around it in code, that would need to be done upstream, or else Fedora would deviate from upstream behaviour.
I strongly doubt that we can not do anything about it and I think that upstream should be able to fix it by a patch. For instance, a script or any other factory helper should check if an instance is already running and delegate to that. http://en.wikipedia.org/wiki/Singleton_pattern
Please do not change the bug resolution to UPSTREAM, if there is no upstream ticket for this issue that has been accepted. Please also read my analysis in bug 956380 comment 8 an onwards (e.g. above in the cloned parts). > For instance, a script or any other factory helper should check > if an instance is already running and delegate to that. Set $TMPDIR, then Firefox will respect that setting, and Claws Mail will use the same $TMPDIR. That's what Claws Mail tries to do by placing a runtime file in, well, uhm, a claws-mail-$UID directory in the system's temporary directory. > http://en.wikipedia.org/wiki/Singleton_pattern Can you elaborate why you think the "Singleton" design pattern would be relevant or helpful here?
(In reply to Michael Schwendt from comment #4) > Please do not change the bug resolution to UPSTREAM, if there is no upstream > ticket for this issue that has been accepted. > > Please also read my analysis in bug 956380 comment 8 an onwards (e.g. above > in the cloned parts). > > > For instance, a script or any other factory helper should check > > if an instance is already running and delegate to that. > > Set $TMPDIR, then Firefox will respect that setting, and Claws Mail will use > the same $TMPDIR. Thanks. This helps. So no patch to the source is needed. > Can you elaborate why you think the "Singleton" design pattern would be > relevant or helpful here? It's possible to do it via GtkApplication and providing an unique identifier, or by help from (deprecated) libunique. The better documentation may be: http://stackoverflow.com/questions/19072161/preventing-multiple-instances-of-a-gtk-application Although, I would provide single instance mode as a feature for the user. On the other hand, multiple instances of claws-mail can crash the settings folder ~/.claws-mail/ .
That has nothing to do with the "design patterns" Singleton, which is about class instantiation _within_ a program. What you really mean is a way to prevent a program from being started once more when it is running already. As pointed out, Claws Mail tries to do that via a socket file in the temporary directory. That works, provided that the temporary directory is the same for every launched instance of Claws Mail. Alternative solutions might hardcode the path or get broken if they also rely on env vars.