Closed Bug 593948 Opened 9 years ago Closed 9 years ago

System integration - Default mail client setting not integrated well

Categories

(Thunderbird :: OS Integration, defect)

All
Linux
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.3a1

People

(Reporter: chrisccoulson, Assigned: chrisccoulson)

References

Details

Attachments

(1 file, 1 obsolete file)

This bug was reported in Launchpad: https://launchpad.net/bugs/630281

Currently, when you set Thunderbird to be the default mail client from the Thunderbird UI on GNOME, it sets "/desktop/gnome/url-handlers/mailto/command" to something like $XCurProcD/thunderbird (on Ubuntu, this path is currently /usr/lib/thunderbird-3.1.3/thunderbird).

This has a couple of problems:

1) It breaks upgrades if the path has the version number in it (which is the Ubuntu bug). Ok, I suppose that could also be argued as a distro-problem too.

2) It causes the default mail client in gnome-default-application-properties to be displayed as "Custom" rather than "Thunderbird". This is because the settings dialog expects the setting to just be an executable in the users path. I suppose that could be changed too, but that isn't how other applications work.

3) Setting the default mail client in gnome-default-application-properties to Thunderbird doesn't stop Thunderbird asking to be the default mail client.

The way I think that this should work is:

1) If thunderbird is in the users path and it is a symbolic link to something in $XCurProcD, set the key to "thunderbird %s", else...
2) Fall back to "$XCurProcD/thunderbird %s".

So, most users with a single install of Thunderbird will have the key set to "thunderbird %s". It also allows for users to download, extract and run other instances of Thunderbird if they want to, and still be able to set them as the default mail client too, without installing them properly (it would just use the full path for those in that case).

Attached is a first attempt at a patch to implement this behaviour, which is working ok here.
Attachment #472595 - Flags: review?(mkmelin+mozilla)
I need to review the patch in more detail but good idea.
Actually I'm carrying a patch with me since years which hardcodes mAppPath to /usr/bin/thunderbird.
I think it would be best if it used MOZ_APP_LAUNCHER instead, since it's what is provided to gnome_client_set_restart_command.

Also note firefox does the same as thunderbird.
Yeah, we're also carrying a distro-patch in Firefox that hardcodes the same to /usr/bin/firefox. 

I wasn't aware of MOZ_APP_LAUNCHER before, I'll have a look at that too. 

Thanks
Here is an updated patch which uses MOZ_APP_LAUNCHER if it is set. If it isn't set, then it falls back to the current behaviour.

I've tested this and it seems to behave correctly with all combinations of relative/absolute path and with/without the launcher in the users $PATH.
Attachment #472595 - Attachment is obsolete: true
Attachment #472595 - Flags: review?(mkmelin+mozilla)
Attachment #474767 - Flags: review?(mkmelin+mozilla)
Assignee: nobody → chrisccoulson
Status: NEW → ASSIGNED
Comment on attachment 474767 [details] [diff] [review]
Set the default mail handler to MOZ_APP_LAUNCHER if it is set

Looks good to me! r=mkmelin

>-nsMailGNOMEIntegration::nsMailGNOMEIntegration(): mCheckedThisSession(PR_FALSE)
>+nsMailGNOMEIntegration::nsMailGNOMEIntegration(): 

Minor nit: trailing space
Attachment #474767 - Flags: review?(mkmelin+mozilla) → review+
Checked in: http://hg.mozilla.org/comm-central/rev/575e67f32009
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Keywords: checkin-needed
Hardware: x86_64 → All
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.3a1
You need to log in before you can comment on or make changes to this bug.