Mark Finkle’s Weblog

Recently, we released Fennec Beta 3 for Maemo (Alpha 3 for Windows Mobile is very close). The new release has several internal changes that might be of interest to add-on developers – or people curious as to how the darn thing works.

Roy Frostig posted an nice article about the changes to the way we render web pages. The results are dramatic: panning is much smoother. The approach also gives us more ways to increase performance and user experience in the future by creating a great foundation.

We also landed what we hope is the final approach for styling the user interface. I previously posted about the affect of themes on performance and how that drives the decisions we make. We are still using the images-for-buttons approach, but we had a problem. Using images-for-buttons doesn’t work for buttons with text, which can be variable in size.

We decided to extend the image-for-buttons approach for all buttons, using the border-image CSS property. Now all of our buttons have a nice, consistent look. We still have performance concerns with border-image, but we should be able to squeeze more speed out of the code. We also use the border-image approach to improve the appearance of the toggle controls and the radio option controls.

In fact, add-ons can, and will in some cases, use the new button styles too. We are in the process of updating the Best Practices document with how to make use of the themes and styles.

So much to do, so little time. My workspace is littered with projects I started but couldn’t find the time to keep going. It’s kinda sad and I do feel guilty.

Sometimes those projects find a new life. Recently, two of my old projects found new life: FizzyPop and js-ctypes are both active again.

Doug Warner has started building a Mozilla Project Wizard on the FizzyPop source code. Doug is requesting feedback for improvements. You can try it out here.

Dan Witte has started looking into moving js-ctypes into the Mozilla tree! There are also plans to add a nice JavaScript wrapper API around the XPCOM too.

I feel less guilty now.

Trying to debug problems in Fennec while running on a mobile device can be a pain. Using the JavaScript Error Console is one way you can track down problems, especially JS coding errors. Some applications, like Firefox, have a UI to launch the Error Console. Other applications don’t. You might not know this, but any Mozilla-based application automatically supports displaying and using the Error Console. Simply launch the application using the -jsconsole command line flag, and the Error Console will open.

This is all well and good on desktop devices, but some mobile devices don’t do a good job of handling multiple open windows – I’m looking at you Windows Mobile. To make it easier to view errors, we added the Error Console as a browser panel in Fennec. It’s hidden by default – you need to use about:config to display it.

• Navigate to “about:config”
• Set “browser.console.showInPanel” to “true”
• Restart Fennec
• Go to the Browser Panels to display the Error Console

It should resemble the standard Error Console. The list can be panned vertically and horizontally. The code evaluator is functional. In fact, Gavin Sharp found an easy way to mimic device window sizes when running a desktop version of Fennec. For example, enter top.resizeTo(480, 800) into the code evaluator to resize the window to match portrait mode.

Mozdev and Mozilla Europe have teamed up to create a Firefox Mobile (Fennec) Add-ons Challenge. The goal is to create or port add-ons to Fennec. You only need to propose a concept for now, but you’ll need to get the add-on ready for the upcoming Mozilla/Maemo developer weekend in Copenhagen on May 30-31.

See Brian King’s post for more details.

I am interested to see innovative ideas for using the limited UI in Fennec, add-ons that focus on mobile-specific functionality, and code that exposes more of the Maemo device functionality to Mozilla (yes, XPCOM is likely involved).

I also wouldn’t mind some applets (either as add-ons or XUL apps) running on Maemo. Think about mobile-specific Chatzilla or FireFTP for example. By mobile-specific, I mean dramatically different UIs, not just porting the existing desktop UI. If many little focused applets work for the iPhone, why not for other mobile platforms? And with XUL/JS, it’s pretty easy to build them. Anyone got a XUL-based Twitter app?

As always, we love to hear feedback from anyone building add-ons or apps on our mobile stack. Post comments, file bug reports, visit the IRC channels (#mobile & #extdev).

Recently, we have seen good discussion on the W3C Web Storage specification. There has been some recent push back on the use SQL, in particular “SQL as SQLite defines it”, in the specification. Counter proposals have been popping up using JavaScript-ish APIs, many using JSON. Some of the APIs store the data as a JSON document or blob, even using the HTML5 localStorage/globalStorage system to persist the data. BrowserCouch and TaffyDB are two nice examples. Both are very JavaScript-oriented, client-side and offer some very nice functionality.

I think the functionality of a good JavaScript storage API will always be the most productive approach to storage, in much the same way we see JavaScript DOM libraries used everywhere. At the same time, I don’t think we should standardize functionality that should be in a JavaScript library, just as jQuery, dojo, YUI or any other DOM library is not the HTML DOM standard. I like having the flexibility of using different libraries.

We already have document-style (blob) storage in a specification and we have JavaScript libraries to make using document storage easy and convenient. The question I see is whether we want relational (tables/records) style storage. Many new JavaScript libraries would blossom from such a storage system and developers would have more choice.

Document and relational storage each has it’s own pros & cons. I’d like to see more discussion about the pros & cons, about performance and about what parts of the storage mechanism browser vendors should be focusing on to make JavaScript storage libraries performant. I’d like to see less bikeshedding on JavaScript storage APIs. I’d really love to see less talk of putting features in a specification that should be in a JavaScript library.

Update: Chris Blizzard’s post discussing Google’s O3D & Mozilla’s Canvas3D is great comparison of high-level vs. low-level APIs. Just replace “3D Canvas” with “Web Storage”.

Felipe Gomes has been busy. We talked on IRC a short time ago about adding a gesture engine to Fennec. He made a video of the current version. The results are very cool. His work is being tracked in bug 476425. The engine is currently packaged as an extension, so you can play with it yourself. Just pull from Felipe’s repository and put the code inside your extensions folder in your profile.

Go digg it!

Using eval() to decode JavaScript you downloaded from a remote website in your extension is just plain wrong. It’s not safe! Don’t do it!

Every now and then, an AMO reviewer will send me an email asking me to help an extension developer workaround the situation. Why? Because AMO will not allow add-ons that eva() JavaScript downloaded from a remote website to be moved out of the AMO sandbox. It’s not safe! Using eval() in an extension can give rogue JavaScript chrome privileges – the ability to do pretty much whatever it wants to the computer.

I finally made an MDC article with more details. The short version is:

• If you’re downloading JSON, use a real JSON decoder, not eval().
• If you’re downloading real JavaScript, use a JavaScript sandbox, not eval().

Mozilla just opened the new source repository (mozilla-central) meaning the next release features will start landing. David Baron posted about landing new CSS selectors. Robert O’Callahan posted about some kick-ass SVG-based CSS effects used to style HTML. This totally rocks and will help push SVG into more of a leading role on the Web.

Look for more cool features, big and small, to start landing with increasing frequency. Some will help chrome developers while others are focused on web developers.

Shaver and I have been talking about getting a decent mechanism for remote debugging a JavaScript session. I have been looking at JSSH. It’s a bit dated, but a great little Firefox/Mozilla extension that adds a huge amount of external flexibility, control and extensibility. The Watir-based web testing system for Firefox (called FireWatir) uses JSSH to control the current Firefox browsing session. The big downside to JSSH is that it has binary components, so you need to build it across platforms and Gecko versions. Yuck!

I have been working on a pure JavaScript version in my spare time, but I can throw that away now that ActiveState’s Shane Caraveo has released an early alpha (called SD Connect) of the same concept. Actually, Shane has a bit more than I had planned, but that doesn’t bother me. Comment’s on Shane’s post pointed me to the MozRepl project as well. I had heard of MozRepl a while ago and I’m kicking myself for forgetting about it.

My goals for remote debugging are a bit different than Shane’s, but there is plenty of overlap. I want to use remote JavaScript debugging to aid in Mozilla’s mobile browser development. I also want to use remote debugging for extension and XUL application development. I realize I may be the anomaly, but a Firebug-like component is _not_ my ideal debugger for chrome (application) JavaScript. For web content JavaScript, sure, but I have Heisenberg uncertainty issues with using a debugger that is itself in the system I am debugging. Therefore, I am very eager to start playing around with SD Connect and MozRepl.

Also, Yay for OpenKomodo spin-offs!

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!