« April 2007 | Main | October 2007 »
June 19, 2007
How May I Direct Your Call
Every so often, I get support requests for Mozilla in my email. It is one of the side effects of working on open source - people can easily find a name and an email address on the web. However, sometimes they are just plain bizarre. Such as this one, which I first thought was spam, but which actually seems to be a real request:
I found all of this stuff in my pluginInstallerWizard.js File and it makes sence to me now why everything is messed up.I purchased my iMac over a year ago and have never been able to get it to work right or to get any satisfaction from Apple. I don't understand why you would set up a program like this.
I had a Computer Tech. check it out and he said it would be better if you fixed it, that it would cost me too much to have him reprogram it. I am on Social Security, I DO NOT HAVE THAT KIND OF MONEY. I am already out $75.00 for the service call, and that was a reduced rate.
So now I am putting it in your hands and heart for you to decide what your going to do about it. I am sure you do not know who I am or care, but I am asking you to. Here is the information about my iMac:
Machine Name: iMac
Machine Model: iMac4,1
Processor Name: Intel Core Duo
Processor Speed: 1.83 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache (per processor): 2 MB
Memory: 512 MB
Bus Speed: 667 MHz
Boot ROM Version: IM41.0055.B08
SMC Version: 1.1f5
Serial Number:And her is the pluginInstallerWizard.js File:
"The Will of God will never take you where the Grace of God will not protect you." God Bless Dale & Joy
The correct answer, of course, is why did the person buy a Mac if they are short on money.
Posted by doron at 7:59 AM | Comments (3)
June 3, 2007
New Password Manager and Extensions
In Firefox 3 (Mozilla 1.9), toolkit now has a new password manager interface called nsILoginManager which isn't backwards compatible with the old nsIPasswordManager interface. MDC has a good article covering the new API, including how extension authors can detect which API to use.
While an extension could store a password on its own (and a couple of extensions I've seen do or have done in the past), using the built-in password API is a better choice, since you get all the extra built-in features for free (master password support, the show passwords feature in preferences). In fact, the top two questions my Gmail Notifier extension gets is whether it uses https to talk to Gmail and if the passwords are stored using the built-in password manager.
Back to the new API, I ran into an "issue" with the Gmail Notifier when I added support for the new API that I thought would be useful to document. I'd like to note that this isn't a bug per se but rather a side-effect of a choice I made that I think other extension authors have made as well. The choice was that using the old api, I was using "chrome://gm-notifier" as the host name when storing passwords. This allowed me to easily fetch all passwords for the extension, users could easily distinguish them in the password manager and it wouldn't interfere with any websites. However, once you udgrade to a new build with the new API, I ran into some issues.
If you've read the new API, you know that it now allows one to store a http realm (for protocol logins) or an action url (for form logins). The issue at hand is that when a user, who for example was using Firefox 2 and the Gmail Notifier, updates to a build that has the new API.
Firefox will migrate the stored passwords to the new format. For the ones the Gmail Notifier added manually from JavaScript, it creates an entry that has no http realm or action url. And nsILoginManager's findLogins method requires either an http realm or an action url to be supplied, else it throws an error. So the Gmail Notifier couldn't search for the entries. Luckily, there is a method to enumerate all logins.
So the solution (aka hack) I had to do was to do my own migration of the passwords. I decided to use "chrome://gm-notifier" as my http realm as well (which may not be a good choice btw). If the findLogins method returned nothing, it enumerates all logins and if the host name is "chrome://gm-notifier", it adds the http realm to it. And then reruns the search.
I'm not sure how many extensions will run into this, but if enough do, perhaps nsILoginManager should take this use case into account.
Posted by doron at 7:41 AM | Comments (4)