Posted on

Extension Developers – Monitor Those Plugins

I’ve mentioned plugin monitoring, a student project from Seneca College, back when the developers sucessfully got their project “marks”. I am quite pleased to see the project actually land in Firefox 3 (Mozilla 1.9) last week (bug 412770).

Fima (gluon) worked through the review process and landed the monitoring portion of the project. Now, extension developers can use an nsIObserver notification (“experimental-notify-plugin-call”) to monitor the processing time used by a plugin. Fima created an MDC article to cover the details. His blog has many posts on the subject.

He also has a Firefox extension you can use to monitor long running plugin code.

It’s a cinderella story complete with fairy godmothers.

Posted on

Firefox 3 – Web Protocol Handlers

Web protocol handlers are a new Firefox 3 feature that gives more power to RIA web applications. Basically, when a user clicks on a link with specific protocol, Firefox can send an HTTP(S) request with the link data to a web application. An easy example is a mailto: link:


Web Master

Normally, if a user clicks this link, Firefox (or other browser) will open the default mail application on the user’s machine and start composing an email message. With so many web-based email applications in use today, it only seems natural that some people would want to use a web-based email application to compose the message.

With web protocol handlers, the web application can register the specific protocol it wants to handle. Firefox will then prompt the user to choose which of the registered applications (web or desktop) it should use to handle the action. Any protocol, real or imaginary, can be used – mailto: is only one example, webcal:, tel: and fax: are others. In the case of the mailto: example, the web-based email application could parse the data passed to it from Firefox to get the parameters of the protocol, perform a sign-on (if needed) and display its “compose” UI.

Firefox 3 will ship with some packaged web protocol handlers. For those developers interested in adding protocol support to their web applications, we have an MDC article explaining the details of setting up and using web protocol handlers. Also checkout the compliance test page we use to test the feature. During the process of getting the packaged handlers into Firefox 3, we ran into some common implementation misconceptions:

  • Web protocol handlers are not just for mailto:! The system is designed for any protocol.
  • Web protocol handlers have no idea about the protocol details. For example, the system does not know that mailto: support to or subject parameters. The system just sends the entire HREF of the link to the registered handler. Be prepared to do the parsing yourself.

Go forth and make web applications rock!

Posted on

RIA is Dead! Long Live Web Applications

RIA (the acronym) has jumped the shark. I find that I can no longer use RIA to describe anything anymore. The definition has been watered down and twisted to the point that nearly any application can be called RIA.

I first noticed this trend last year. Adobe and Microsoft evangelists started ping-pong blogging about what RIA meant. Scott Barnes of Microsoft even went so far as to redefine the acronym, from “Rich Internet Application” to “Rich Interactive Application“. That, along with some other “we can be better than the Web” posts caused Dare Obasanjo to create a great post: If you Fight the Web, You Will Lose. I also liked Anil Dash’s “ice cubes in water” analogy. I can see why Microsoft is pushing Interactive and not Internet, which would necessitate making Internet applications.

Fast forward to the present and Ryan Stewart’s post on the ever changing definition of RIA:

Let’s first bite off the question of what desktop applications constitute RIAs

None. RIA isn’t about desktop applications

I think things like Mozilla Prism, Adobe AIR, Curl Nitro, and Microsoft WPF are all examples of desktop RIAs.

Desktop RIA? WPF? WTF? Sounds like an oxymoron to me

In general, I think RIAs as a whole should be:
* Using web technologies

Wait for it. He’s softening you up for what’s next.

I also think that the best RIA platforms should have:
* A good designer/developer workflow story
* At a technical level business logic and user interface should be very cleanly separated so that the UI can easily be enhanced.

I fail to see how these relate to RIA, but I do see how it relates to Adobe products. Adobe products that “use web technologies”, but not the web itself. Maybe RIA means “Really, It’s Adobe”

It’s no wonder people are confused by RIA discussions. I think I’ll stick with web applications from here on out. RIP RIA.

Posted on

JS-CTYPES Status

Unfortunately, the js-ctypes project got back-burnered for a while. Fortunately, some great contributors swooped in and landed some really nice bits. Fredrik Larsson helped out on some Linux problems (bug 416119), filled in ANSI string support (bug 416229) and setup an xpcshell test framework (bug 427286).

The Atul Varma came to my rescue by adding support for OS X and fixing a small bug (bug 429063). Atul also added build instructions to the wiki. Brahmana found a bug too and posted a patch (bug 413783).

We are getting pretty close to a usable library. The next step is struct support. The current plan is to do something like this:


// define the struct
var POINT = [{"x": INT32}, {"y": INT32}];

// use the struct when declaring the function call
var pointsEqual = library.declare("PointsEqual", STDCALL, BOOLEAN, POINT, POINT);

// initialize objects that looks like POINT
var pt1 = {"x": 10, "y": 20};
var pt2 = {"x": 20, "y": 20};
var result = pointsEqual(pt1, pt2);

// "result" should be false :)

The wiki page has bugzilla and SVN information too. Feedback welcome. Patches welcome!

Posted on

Bubblemark is an RIA Benchmark?

The Adobe RIA crowd have been causing some echos in the chamber lately over Bubblemark, an animation benchmark originally released over a year ago. Personally, I have no real skin in the game, but a game it is. Some Flash developers were curious about variations in the results when run on different browsers, platforms and in the AIR runtime. It makes for some interesting reading and I came away with a better understanding the variations, browser limitations and timer mechanisms.

What caused me to gush milk out my nose was reading that this benchmark appears to be some kind of de facto standard for RIAs. No way! Someone is going to have to explain, speaking slowly and using big letters, to me how rendering an bunch of bouncing balls and calculating a framerate from the bouncing balls is a benchmark for RIAs. I guess if your RIA is an animation of bouncing balls (or non-balls too, I guess), this test has you covered. Thankfully, I’m not the only one. The Flash guys have more than a few gripes with the test. Sean Christmann sums up my biggest gripe:

The test just moves balls around! This is my biggest beef with the benchmark because it only tests one simple aspect of the rendering engine in these technologies, which is bitmap translation. How do bitmaps moving around the screen tell you anything about the capabilities of the respective technologies? Do the JavaFX guys really think optimizing this usecase will make their technology relevant? The only thing Bubblemark will tell you is which runtimes might best handle bitmap particle emitters….thats about it.

Instead, I’ll offer that the Bubblemark test has value in that many different technologies have implemented the test. Therefore, it provides some level of benchmark for how different technologies can be optimized to implement the test. Of course, I could be way off base here and the RIA of which they speak is actually “Really Interesting Animations.” If so, whoops, my bad.

Posted on

Extension Developers – Chrome URI Changes & You

Over the weekend, code landed to restrict the ability of web content to access “chrome://” resources (see bug 292789). This shouldn’t affect many extensions since the restrictions are focused on web content, not chrome content. However, if your extension injects content into the web content, you could be affected. An example can be found in bug 428848. Venkman can’t load venkman-source.css, a stylesheet that is injected into unprivileged, web content.

The solution to this problem is a new chrome manifest flag – contentaccessible. Using contentaccessible, an extension author can say “Yes, I’d like my extension’s chrome package to be accessible to web content.”

Note, in bug 292789, that chrome://global and chrome://browser packages are exposed to content by default. This is required to keep remote XUL (XUL loaded into web content) working.

See Wladimir Palant’s post on this topic too.

Posted on

Soylent Green Is People!

And making Firefox 3 ignore extension compatibility checking is wrong!

Firefox 3 is really close final release. Many of you have started using Firefox 3 for your daily browsing, as have I. You might discover that some of the extension you love have not been updated to Firefox 3 or maybe just not updated to the latest beta. So you search the web and find posts and tools for magically making old extension “work” in Firefox 3.

The Lifehacker post says “Make Your Extensions Work with the Firefox 3 Beta.” Nightly Test Tools adds a button to “Make all compatible.” This is snake oil my friend and you could be faced with nasty consequences.

These methods DO NOT make your old extension updated to work in Firefox 3. They turn off Firefox’s builtin extension version checking system. These methods should only be used for testing, not everyday browsing.

More than a few of the top-crashing bugs (reported when Firefox crashes) are due to users running old, incompatible add-ons. Please, turn on the compatibility checking. If you can’t wait for your favorite add-on to be updated, maybe it’s time to look for a new add-on. Firefox 3 is the leanest, fastest, most feature packed version we have ever released. Don’t foul it up with old crappy add-ons.

Posted on

Extension Developers – Update or Fade Away

Firefox 3RC1 is just around the corner. Surprisingly, more than a few of the current Top 100 add-ons on AMO are not updated to work in Firefox 3. I say “current” because when Firefox 3 ships, those old add-ons will no longer be in the Top 100. Alex Polvi has a chart (updated daily) showing the status of Top 95% of AMO add-ons (by usage). You can see that many of the Top 100 have been updated to at least Firefox 3.0b3 or greater.

Many of the non-updated add-ons are themes. Themes are hard to create in the first place and with significant changes to the Firefox 3 UI, updating themes from Firefox 2 could be a daunting task. Worse yet, getting a them to somehow support Firefox 2 and 3 in the same bundle is not trivial.

AMO was recently updated and is constantly improving to make things easier for add-on developers. Being able to host separate bundles for different versions of Firefox would be a big help.

The remaining non-updated add-ons will likely fade away after Firefox 3 is released unless the authors or someone else (with the author’s permission) decide to do the work needed to update to Firefox 3. Keep in mind, add-ons in the Top 100 have hundreds of thousands of daily users. Add-ons in the Top 10 have millions of daily users.

Just as in nature, “survival of the fittest” applies to add-ons too. Let’s hope we can avoid one of those mass extinctions.

Note: To those add-on developers who went through the effort to update your add-ons to Firefox 3 alpha or beta (1 or 2), please take the small amount of time needed to push your add-on to Firefox 3.0pre. Don’t let your users miss out on your add-on when it’s soooo close to completely updated.

As always, #extdev on Mozilla IRC or the extensions newsgroup for help.

Posted on

Have XULRunner, Will Travel – It’s Mobile Baby!

Mozilla’s Mobile group has been hard at work getting the Mozilla platform running on some mobile devices. Recently, Brad Lassey posted about getting XULRunner working on Nokia’s N800/N810 (Maemo) Internet tablets. He linked to a XULRunner binary and showed some XUL-based applications running on an N810.

This is big news for me because wherever you find a XULRunner, you’ll find me: building the runtime, writing sample applications, creating platform components and generally having a great time. I even managed to get myself an N810 from the Mobile group. It’s a pretty cool little device. We already have some bugs filed to better integrate the Mozilla platform with the Maemo platform (see bug 426291, bug 426292, bug 426293 and bug 426299). Bug 426355 will start making nightly XULRunner builds for the N800/N810.

So now I am adding support for mobile XULRunner and XUL application development to my list of duties. After all, developing XUL applications and extensions should be the same on WindowXP as it is on the N810 – and it is!

That’s right, I said extensions too. Remember, Mozilla is making a mobile browser and it will rock!