Category: Javascript

Posted on

Embedding the Error Console in Fennec

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.

Posted on

Ready for a Challenge?

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).

Posted on

Day Dreaming about Web Storage

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”.

Posted on

Fennec & Gestures

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!

Posted on

Extensions & XMLHttpRequest & eval – Oh My

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().
Posted on

Here We Go!

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.

Posted on

Remote Debugging JavaScript

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!

Posted on

Do You Smell Something?

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!

Posted on

Firefox 3 – Offline App Demo – Part 2

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 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)

offline demo app

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.

Posted on

A Little XPCOM Magic – JavaScript Callbacks

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.