Per my social contract, I am making 0.6.2 beta available before placing it on addons.mozilla.org.
It's available at http://www.kaply.com/operator/operator.xpi
Significant items in this release include:
I have tested this release significantly, including running JSLint against all code, testing migration from Operator 0.5 and 0.6.1, as well as starting a test suite. If you find problematic pages, please add them to the test suite.
Please report bugs here.
Thanks!
Jonathan Watt pointed out some preferences you can set to ensure that the JavaScript code in your extension is "clean."
javascript.options.showInConsole set to true causes chrome JavaScript errors to be displayed in the JavaScript console. This preference is essential when you are writing/debugging your extension. If you don't have it set, your extension will simply not work and you won't know why.
javascript.options.strict set to true causes JavaScript to parsed in such a way such that you will see errors about bad code on the console. If I had set this preference, I would have found my problem.
In my social contract, I taked about using JSLint.
There were two problems reported with the current release of Operator that were very strange when I heard about them. One was that Firefox didn't honor the "Show the tab bar when only one tab is open" preference anymore and the other was that external links opened in new windows. I spent a bit of time debugging the problem and tracked it down to this code:
disable: function()
{
toolbar = document.getElementById("operator-toolbar");
toolbarbuttons = toolbar.getElementsByTagName("toolbarbutton")
for(var i=toolbarbuttons.length - 1; i>=0; i--) {
if (toolbarbuttons[i].id != "operator-options") {
toolbarbuttons[i].setAttribute("disabled", "true");
toolbarbuttons[i].label = toolbarbuttons[i].getAttribute("origlabel");
toolbarbuttons[i].setAttribute("label", toolbarbuttons[i].label);
}
}
},
Do you see the problem there? Because I didn't have "var" in front of toolbar, I was affecting the global variable toolbar which was causing all the problems that people were seeing. Anytime an extension uses a variable with a common name without putting "var" in front of it, it risks overwriting other global variables in the browser.
Running JSLint through my code with the "Detect undefined variables" option would have found this problem and other problems as well. When I used JSLint, I found many cases where I had done this and I was able to easily find and fix them all.
Some of the other things I was able to fix as a result of JSLint included missing semicolons, unnecessary global variables, using == where I should use ===, as well as general cleanup. One error in particular (Weird construction. Delete 'new'.) encouraged me to reevaluate some code I had written and I was able to clean it up considerably.
So I would encourage you to at least attempt to run JSLint against your extension to make sure you aren't creating any side effects you don't intend.
Note that there is one construct that JSLint complains about that is very common in Mozillla/Firefox source code:
Components.classes["@mozilla.org/embedcomp/prompt-service;1"]
.getService(Components.interfaces.nsIPromptService);
JSLint would prefer you wrote it like this (note the location of the period)
Components.classes["@mozilla.org/embedcomp/prompt-service;1"].
getService(Components.interfaces.nsIPromptService);
I went ahead and made this change in my code to avoid seeing the JSLint errors, but your mileage may very.
In most software installations, the user (you) agrees to a EULA where limitations and restrictions are spelled out. By reading the EULA, you can make a decision as to whether or not you want to install the software. The EULA in a sense gives you the developer's side of a contract, and by agreeing to the EULA, you are deciding to accept that contract. A EULA could have a statement like "this software will slow down your machine" or "this software will cause all other applications to break," but you have the opportunity to read these statements in the EULA (usually) and decide whether or not to install the software.
Extension development, however, involves an implied social contract, because in most scenarios, a user is not presented with a license agreement before installing the extension. Here are a few examples the developer's responsibilities in that contract:
With previous versions of Operator, I was not proactive enough in making sure I didn't break the contract. (Part of this was related to the fact that I committed to a specific release date, so I rushed things a little bit.) So the goal of this post is to outline for you (and for me) a basic social contract to make sure that what happened with Operator in the past does not happen in the future.
So there you have it. The beginnings of a developer's social contract. So where am I in meeting this contract?
Per my contract, I am not committing to a specific day for the next release, but I am hoping to have something available this week (the week of Jan 7, 2007).
Thanks for your support!
Moving right along...
One of the ways that I verify that Operator is working correctly is by comparing against other sites that do similar functions. For instance, I might go to eventful.com or upcoming.org and compare their Yahoo! or Google calendar to mine.
One of the things I have discovered is that upcoming.org's use of microformats needs some serious help. Let's use this event to demonstrate the various problems.
Problem 1 - Missing information in the microformat
Notice that on the page it indicates the event is from 11AM to 5PM. If you add this event to Yahoo! with Operator, you won't get an end date. If you use the Yahoo! calendar functionality built in to upcoming.org, you will. The end date (dtend) is not specified in the microformat so I can't get it. Here's another one. Notice that there is no phone number on this page at all. But if you add it to your Yahoo! calendar, you'll see a phone number. Also, country information is missing from all pages, even though it is used by upcoming.org's Outlook export feature.
Problem 2 - Extra information in the description
You might have noticed when you added that event via Yahoo! calendar, that the word "Description" appeared at the top of the description. This doesn't happen when you add the event using upcoming.org's Yahoo! functionality. This is because upcoming.org has tagged their description incorrectly. Here's how they tag them:
<div class="description"> <div class="small">Description</div> Text of the description </div>
The problem here is that the word "Description" is contained in the description. The correct tagging shold be:
<div class="small">Description</div> <div class="description"> Text of the description </div>
Or something similar. They also do this with category. While this might not seem like a big problem, wait until you see what it does with url...
Problem 3 - URLs are tagged completely wrong
On that upcoming.org page, you might try selecting the Web Page option from the event in Operator and see what happens (assuming you are in microformats mode and not action mode). Notice you'll get an error that the URL can't be loaded. This is because the URLs are tagged completely wrong. Here's the URL for that page:
<div class="url"> <div class="small">Homepage<div> <a href="http://blog.coworking.info">http://blog.coworking.info</a> </div>
At first glance, this just looks like the problem 2, but it turns out to be much worse in this case. If the url class is not specified explicitly on an anchor tag (which it isn't in this case), the specification says to use the entire text content of the url class as the URL. In this case, that would be Homepagehttp://blog.coworking.info. So this turns out to actually break functionality in operator.
So please upcoming.org, fix your bugs. You're making Operator look bad
OK, so if you were one of the unlucky people that got 0.6 with the migration problem, you probably have nothing on your Operator toolbar.
The problem is that it got half migrated, so because we see some preferences, we don't recreate the default set.
Here's how to fix it:
Type about:config in the URL bar and press enter.
Type operator in the filter at the top.
Delete (right click and select reset) ALL preferences that start with extensions.operator.
Once you've done this, close and restart the browser and you should get the default set.
Again, my apologies.
Let's try this again without the migration bug...
Operator 0.6.1 is available from addons.mozilla.org.
Here's what's new in this release:
I hope this version addresses some of the concerns people had about the Operator UI as well as performance. Please give me any feedback you have!
FYI, for the next release I'll be working on:
Enjoy!
Operator 0.6 is available from addons.mozilla.org.
Here's what's new in this release:
I hope this version addresses some of the concerns people had about the Operator UI as well as performance. Please give me any feedback you have!
FYI, for the next release I'll be working on:
Enjoy!
