Firefox 4 beta - AT Vender Relief

Success. Earlier this month I posted an alert about the temporary Windows screen reader bustage with our Firefox 4 betas. Since then Marco posted a status update about our temporary and long term fixes. We worked together, along with the screen reader developers to provide 3 solutions. The first is a temporary hack, and the other two are long term fixes and probably generally useful anyway:

1. The "emulation" hack. For known AT that require them, we resurrected the windows that were recently removed from Firefox. We intend to only create these windows for legacy AT so that users don't necessarily need to pay for upgrades for their software to use Firefox 4.
2. The speedy document accessors fix. We added quick methods to get parent and child documents, and indexed access to documents.
3. The QueryService fix. Provide a special service ID for getting the accessible object that represents the browser tab content document that contains the accessible object queried. Here's some sample code to illustrate how you might use this service:

static const GUID SID_IAccessibleContentDocument = {0xa5d8e1f3,0x3571,0x4d8f,0x95,0x21,0x07,0xed,0x28,0xfb,0x07,0x2e};

// Assuming you have a CComPtr<IAccessible> accessible
CComQIPtr<IServiceProvider> serviceProvider = accessible;
CComPtr<IAccessible> accessibleDoc;
serviceProvider->QueryService(SID_IAccessibleContentDocument, IID_IAccessible, ( void**) &accessibleDoc);

If the 'accessible' is in web content then 'accessibleDoc' represents the main content document that contains 'accessible'. It works in all cases we tested, including special documents like about:addons, as well as documents with iframes where we still always return the main content document. This support is in our nightly builds and will come with FF4 beta7. I hope this will make it easier to manage your cache and context switching.

Thanks for reading.

Go ahead browser, make my day...

This command (I use OS X) takes the patches in my mercurial queue (which I tend to name bug-#) and opens a browser tab for each.

hg qseries | sed 's/bug-/https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=/' | xargs open

There's probably 94 better ways to do that but meh, and barely blog worthy perhaps... but this way I'll have a record of the command for when I forget. And smart people can add comments showing me better ways :)

I guess having FF restore my session is a good one.

There's something about prototypal inheritance...

Let's look at some JavaScript, and today I'll ask Crockford to pass the sugar:

Object.create = function (o) {
    function F() {}
    F.prototype = o;
    return new F();
};

Now let's create an object a, and a two objects b and c based on a.

var a = { name: "a" };
var b = Object.create(a);
var c = Object.create(a);
c.name = "c";

At this point both a and b have name "a", and c has a customized name "c". Now lets change a:

a.name = "foo";

Objects a and b now have name "foo", and c still gets to keep name "c" (a good language design decision methinks). Since a is just a mutable object we wield this sort of godly power to change or inject DNA. Every time I come back to it, it tickles me.

Scratch-ing an Itch

I gave a talk a few hours ago at the inaugural Scratch conference at the MIT Media Lab. Having first used Scratch last week, and leaving for the airport at 4am this morning I found myself reflecting...

What am I doing?

The title of the talk is "Scratching All Itches Equally" and originally listed Gregory Rosmaita, Liddy Nevile, and Jutta Treviranus as speakers. Gregory and Jutta couldn't make it so I was asked to jump in.

Here is the description in the program guide:

A discussion of strategies for ensuring that Scratch is usable by all, whether one can see the screen, or use a pointing device or an on-screen keyboard. The goal of the panel is to discuss Scratch’s architectural framework to ensure that it is capable of communicating with operating system accessibility APIs, as well as platform-agnostic APIs, such as IAccessible2 and ATK/AT-SPI (Assistive ToolKit/Assistive Technology Service Provider Interface).

Liddy and I realized that the audience was going to be made up mostly of teachers so we decided to turn the talk into less of an engineering discussion, and more of a brainstorm. We framed the storm in the context of Scratch, and accessibility, or disability in the wide definition.

Over lunch, it was cool to hear people from our talk bringing up topics from our brainstorming to groups who hadn't attended.

What interests me most about Scratch is that it is playful programming that kids (well, not just kids) can pick up rather accidentally in order create and express their ideas. It makes a lot of sense to me that this kind of tool should be made accessible to all children, regardless of culture, gender, or physics. When you only allow a subset of people to participate in creating and making, you lose some of the most valuable and insightful influences; you stagnate.

Thanks for reading.

"Code Talks"

If you build it will they come?

http://wiki.codetalks.org/

We need a new logo.
We need authors.
We need advice on organizing the wiki.
We need to figure out what we want this wiki to be.
We includes you.

Thoughts?

Debugging JavaScript evals

Note to self... when debugging dojo in firefox... always check the script option: "Show eval() sources" in firebug.

You might need to check this after updating minefield and/or firebug.

Thanks for the reminder today Becky.

Do bug references taint code readability?

Sometimes we write code that looks slightly odd or unpleasant, but it works around (or fixes) a bug, a bug which otherwise is perhaps beyond our control (e.g. some interaction issue with a closed source tool). We write the code as best we can to make it self documenting, perhaps adding a short comment to describe why the workaround exists. We write an automated test to protect against regressions. We refer to the bug # in the tests for easier forensics should things go awry. We are fashionable.

Yet we are still worried about someone coming along and shredding our unpleasant fix, forgetting about the regression tests, and reintroducing the bug.

Refer to a bug number in a source code comment?

How fasionable is that? I've googled but couldn't find much on the topic. I've seen it done quite a bit in the Mozilla codebase, and I'm inclined to think it has merit in some cases. I wonder what others think.

Anyway... this blog was inspired by a dojo meeting a few months ago. I let it sit unpublished for a while... until a time when I'm mentally exhausted and just don't care what blatherings I post...

Thanks for reading.

Debugging Dojo

I'm a firebug fan so I use fireclipse. It is basically firebug with support for debugging into eval() expressions. It is quite impressive considering SpiderMonkey is not designed to support easy debugging of eval(). If you are curious about the bug I recommend reading John Barten's great description of the problem. I'm not sure when that might get resolved.

In the meantime, I'm grateful for fireclipse.

IMG onload reassignment

Hacking on a dojo dijit widget today I came across some strange behaviour that only seemed to happen in IE. Turns out the reassignment of an image node's onload was causing the new onload hander to fire. Here's the code that reassigns onload:

img.onload = function(){ self.onImageLoad(); }

IE is not open source so I can't diagnose exactly why the onload fires when reassigned. I worked around it by making sure that the premature firing would not be harmful.

Javascript Hacking at CSUN

We hacked on dojotoolkit ARIA stuff today in the Mozilla hacking room. Shown in the pic above are Becky Gibson, Simon Bates, Gijs Kruitbosch, and Earl Johnson (photo by David Bolter).

The Mozilla booth is busy and lots of people have expressed their appreciation. So much is happening here and theres so little time to blog about it!

We're still hacking/meeting now and I hope to blog in more detail tomorrow...

XUL Trees, Localized Actions, TBird Tracker, and ARIA

I've closed a number of bugs since my last post but today was particularly fun.

XUL Trees

I made a breakthrough on a pesky focus bug which turned out to be a core problem. There is a clever caching mechanism in the accessibility infrastructure for storing and retrieving accessible objects (pointers really). Trees are special beasts which handle their own caches. It turns out the accessible objects stored in a tree's cache are hashed on the row and column (aRow * kMaxTreeColumns + columnIndex). Now the bug...

When a row was deleted, the remaining rows shuffled up (as rows tend to do when a row above them is deleted). So the next row in the tree (yeah I know "row in the tree" might sound funny) will now have same row index as the row which was deleted. Because the next row is focused by default it will cause a focus event to fire. The focus event fires and reports the accessible object to be the one it pulls out of the cache hashed on the row value (column won't be different). This object is erroneously the deleted row.

The fix? Well we need to update the cache when these kinds of DOM mutations occur. My current patch builds on Aaron's work to fire a new kind of dom event which results in a tree invalidation event which will cause a cache update.

What remains is to possibly optimize the cache updating strategy as well as to consider a more broad solution for other kinds of tree mutations.

Localized Actions

Accessible action names are no longer to be localized in mozilla. This came from discussion on the gnome-accessiblity-devel list on the thread "Are action names localized?". I'm currently assigned to this bug.

Tbird Tracker

I added a Thunderbird accessibility tracker bug last night. I thought I'd just note it here so that I had it handy and in case others take interest.

ARIA

Tomorrow I officially embark on another Mozilla funded project building ARIA, or "Accessible Rich Internet Applications". I will joining the dojo ARIA efforts of Becky and others.

Mozilla source code contribution!

I'm happy to report that I've being finding more time lately to work on patches to fix Thunderbird accessibility issues. In fact...

My first patch finally went into the mozilla codebase today!

First the technical bits...

The patch makes an email message's graphical status indicators accessible. These indicators include things like read/unread status which is normally a small or large green dot. To achieve this I implemented GetCellValue for the XUL tree view (part of the nsITreeView interface, implemented in a C++ class known to tbird developers as msgDBView). Implementing GetCellText to return text for these status indicators would have created conflict between the text and the graphical icon. Implementing GetCellValue provided a way for the accessibility infrastructure to query for a textual representation of the various status areas (which I added to nsXULTreeitemAccessible::GetName).

The patch touched the following modules: accessible, dom, mail, mailnews.

Now the fuzzier bits...

I can't say enough about how welcoming this community has been to me, and it has been an absolute joy working with them. I think as I began my Thunderbird work I was too hesitant to seek help from the community for fear that I would draining valuable resources, but that perspective has changed and I think I can really help out here in the long term. That will probably have to wait however as it appears I am soon going to be doing some ARIA work, in particular, dojo accessibility! I'll post something on that later.

For me, this was a really interesting first bug fix.