Mark Finkle’s Weblog

Mozilla is starting a new newsletter, about:addons, strictly for add-on related development and hosting. A lot of changes were made to the way extensions are built and hosted during the last Firefox / Mozilla release cycle. Many changes and new features have been happening on AMO as well. It can be hard to keep track of the add-on related changes with all the other types of information coming out of Mozilla, on MDC or blogged on Planet Mozilla. With that in mind, it was decided that a dedicated newsletter could be the best way to get add-on information to add-on developers.

Deb Richardson started the about:mozilla newsletter about seven months ago and it has been a great way for community members to keep informed about news in the Mozilla ecosystem. We’d like to create the same kind of success with about:addons.

Dave Townsend covered some of the details in his post. Use the sign up page to subscribe. The newsletter is primarily an email-based service, but we will post it on DevNews weblog too.

We hope to get the first newsletter out sometime next week. We’ll post more information about submitting news as we get things nailed down. For now, feel free to leave comments about what you want to see.

[Thanks to Jim Mathies, Firefox developer, for writing this post - with minor edits]

Firefox 3 will have some support for Parental Controls on Vista (see bug 355554). The download manager is now aware of situations where content gets blocked by proxies. Downloads that are blocked display correct UI message to indicate what happened.

A good example would be a right-click Save As on an image link that’s offensive. Something like that might get blocked by a proxy, so we handle that case correctly in the download manager.

As for the main browser area, inline display of offensive content tends to be handled by the proxies themselves, so that content downloaded by the browser will get replaced by some sort of “blocked message” content, or it’ll simply be displayed as a broken image. In general, we rely on proxy blocking in the main window right now. This is something we want to eliminate down the road by detecting blocked content before we issue the request and display our own message.

In preparation for that and for more general use, we now have an interface (nsIParentalControlsService) that interacts with the operating systems parental controls services, so extension developers and XULRunner apps can respect local parental controls restrictions.

Currently, we support querying of application level flags like file blocking, logging of blocked content, and requesting overrides for a single or list of URIs. We don’t yet support for querying whether a particular URI will be blocked, but we’ll be adding that soon. Until then, developers can rely on HTTP status results to detect blocked downloads.

Looking forward to Firefox 3.x, we’ll have better support for inline blocked content, and we’ll be adding checks of file blocking flags in other places, like the extension manager. We weren’t able to get that in this release because it required UI changes and parental control support was added pretty late in the release cycle.

[thanks Jim]

Samer Ziadeh will be working on a Summer of Code project to enhance FUEL. He is looking at some feature requests found in bugzilla, bug 406974 and bug 409279 specifically. Samer has already done some work with FUEL. The past semester, he ported much of the code to work in Firefox 2. It wasn’t a perfect fit as Firefox 2 is missing some integral new functionality supported in Firefox 3. Without it, backporting to Firefox 2 became difficult.

Samer will be hanging out on IRC in #extdev, so be sure to give him some encouragement (and a feature request or two).

Oh yeah, it’s this crappy post from ReadWriteWeb on the new Google Maps Flash API. I have no problem with a Flash API for Google Maps. Power to the people! But I did have a massive gag reaction to the following fairy tale:

A substantial portion of the web’s creativity can be found in the Flash developer community. Adobe’s AIR platform is one of the hottest development environments in the consumer market today and is being deployed with increasing frequency in the enterprise as well. Live Google Maps in Flash are likely to be used in even more creative ways than the existing javascript API has been. Javascript can be used in AIR but it’s rarely used as attractively as Flash often is.

It doesn’t end there, although my ability to keep food down did:

Throw some Flash Google Maps into the mix and things are liable to really get interesting.

• Are you kidding me? Hey, I’m glad Flash is open, but I have no love for an alternate Web.
• More creative ways than the JS APIs? Haven’t seen any creative uses of JS have you?
• One of the hottest development environments? For making Twitter clones?

The rest of the post is great!

Extension Developers! Yeah, You!

AMO has flipped the switch to support MaxVersion “3.0.*” so make those final version updates now. Firefox 3 RC1 is releasing very, very soon. Yes, “3.0.*” is the final MaxVersion you’ll need for Firefox 3, so don’t delay.

Copied for your reading pleasure:

What this means for you as an add-on author is that after you test with the Firefox 3 release candidates, you can use the Developer Tools section on AMO to bump your version number without having to upload a new version of your add-on.

For completeness, if you want to support Firefox (and none of the alpha’s, betas and pre-releases), here are the recommended version ranges (minVersion - maxVersion) to use:

• Firefox 2: 2.0 - 2.0.0.*
• Firefox 3: 3.0 - 3.0.* (Note: that with Firefox 3, it’s a three part version number)

Yay! for the end of update madness! Now go and do it!

Last year (wow, that long ago?) I made a simple demo to show Firefox 3 offline capabilities. A lot has changed between then and now. Firefox 3 offline capabilities changed significantly to align better with WHATWG offline specification. The biggest changes involve dropping support for our own <link rel="offline"> mechanism and supporting WHATWG manifests and application cache. The specification gives some details on how it works. There is an MDC article on using offline resources in Firefox 3.

Since so much has changed, I decided to update the demo application. Here is the overview of the application, updated where needed:

A Simple Demo - Task Helper

The application is a simple task list system. The current functionality includes:

• Add tasks - Enter text in field and press ‘Add’
• Complete tasks - Mark completed tasks and press ‘Complete’
• Remove tasks - Mark tasks and press ‘Remove’
• Data is stored as JSON and XHR is used to interact with server (PHP)

Nothing fancy. However, the application is “offline-aware”, meaning:

• Application resources (HTML & JS) are listed in the offline cache manifest. This manifest must be served as “text/cache-manifest” and follow the manifest rules.
• Before interacting with server, online status is checked. If online, use XHR. If offline, use DOMStorage.
• Online/Offline status is monitored using events. When the application switches from offline to online, data is resync’ed with the server.

There is really nothing fancy about the offline stuff either, but putting it all together does make for a neat application. Using the latest Firefox 3 (beta 5 or nightly), you should be able to:

• Use the application while online.
• Go offline using the “Work Offline” menu. The event log should show that the app went offline.
• Continue to use the application while offline.
• Restart browser.
• Switch to offline (or have no network connection).
• Enter URL to app (or use a bookmark).
• Start using app with data from last session.
• Switch to online. The event log should show that the app is back online and has updated the server with any offline changes.

Try it: Task Helper
Source code: todo-offline.zip

Note: The data is stored in a simple, shared JSON file on the server, managed with a simple PHP file and reset every hour. No fancy databases with multiple session support.

XPCOM is, currently, a core Mozilla technology. Developers use XPCOM for a variety of reasons, many of which result in XPCOM components being accessed from JavaScript. XPCOM uses IDL to describe interfaces. This can make XPCOM components a bit rigid and not feel right in JavaScript. Recent support for optional parameters in IDL has helped a little. Another helpful concept is using JavaScript functions in place of an IDL callback interface. For example:

[scriptable, uuid(...)]
interface StringParserObserver {
  void onWord(string word);
};

[scriptable, uuid(...)]
interface StringParser {
  void parse(string data);
  void addObserver(StringParserObserver observer);
};

In order to use this interface from JavaScript, you would have to implement the StringParserObserver using JavaScript. A nicer approach would be to allow someone to pass in a JavaScript function to use as the callback. The good news is you can! Better news is that it is a one line change to your IDL!

Just add the “function” attribute to the interface and XPCOM will handle the rest.

[scriptable,function, uuid(...)]
interface StringParserObserver {
  void onWord(string word);
};

There is a new MDC article with more details here.

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.

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:

<a href="mailto:webmaster@example.com">Web Master</a>

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!

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.