442483 - nsiShellService.openApplication() Fails Reading Registry

Status: RESOLVED WONTFIX

(Firefox :: Shell Integration, defect)

Description

[David White]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

I have written an addon (ThunderbirdBiff) that makes use of the openApplication() method for starting the default mail client. This has worked well enough on FF2 but FF3 breaks it.

I have found that under FF3 and using Sysinternals RegMonitor, the registry entries being read to find the default mail client are just dead wrong. In FF3, the code attempts to open HKCU\Mail followed by HKCR\Mail.

The correct locations are HKCU\Software\Clients\Mail followed by HKLM\Software\Clients\Mail. Using RegMonitor, I have been able to confirm that FF2 is doing the right thing. In looking at the CPP code online, it appears that the FF2 code is far more robust in addition to being CORRECT (in this issue anyhow). I cannot understand why this has been lost in moving to FF3.

Finally, I have seen some bugs listed here suggesting that the class should be removed. This would break my addon and several others.

Reproducible: Always

Steps to Reproduce:
1.In error console
2.Place the following in the JS evaluation area:

Components.classes["@mozilla.org/browser/shell-service;1"].getService(Components.interfaces.nsIShellService).openApplication(Components.interfaces.nsIShellService.APPLICATION_MAIL);

3.Press Evaluate key
4.An exception is tossed - NOT AVAILABLE
5.The exception comes from OpenKeyForReading() inside the class. This is because the sought registry key is not (and should not) be found.
Actual Results:  
Get exception thrown. Wrong registry key(s) being sought.

Expected Results:  
Should succeed in starting the default mail/news client.

Code should look for correct registry keys. See FF2 version of the class for correct usage.

Comment 1

[Robert Strong (they/them - no direct email)]

That code is dead and will be removed sometime in the future via Bug 324361.

Comment 2

[Mark Smith [:mcs]]

We encountered this same issue with an extension we are working on.  It looks like the regression was caused by the fix for bug # 370571.  Search for -1002,43 +663,40 in the patch (attachment 282816 [details] [diff] [review]).

Robert -- given that this interface exists in Firefox 3 but does not work, do you think a patch would be accepted for an upcoming 3.0.x release?  Or should we pursue a different solution?

Comment 3

[Robert Strong (they/them - no direct email)]

(In reply to comment #2)
> We encountered this same issue with an extension we are working on.  It looks
> like the regression was caused by the fix for bug # 370571.  Search for
> -1002,43 +663,40 in the patch (attachment 282816 [details] [diff] [review]).
> 
> Robert -- given that this interface exists in Firefox 3 but does not work, do
> you think a patch would be accepted for an upcoming 3.0.x release?  Or should
> we pursue a different solution?
A patch might be accepted (I don't have a problem with a fix for this) but this will likely go away in the future. I believe the current functionality can be created in js (at least on Windows) and that would be the preferred course.

Comment 4

[Swarnava Sengupta (:Swarnava)]

Firefox 3.0 is now EOL, please try latest version of Firefox and feel free to open if it reproducible on latest build
* http://getfirefox.com
for support
* https://support.mozilla.org/questions/new