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.
That code is dead and will be removed sometime in the future via Bug 324361.
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?
(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.
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
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.