What’s up with all those windows?

This blog post has to do with the reasons why Firefox 4.0Beta 5 and Beta 6 are totally inaccessible to most, if not all, Windows assistive technologies, and also cause problems with some mouse drivers and such.

It all started with Bug 130078, a sequence of digits probably everyone in the Mozilla platform team will memorize for a long time. 😉 What this patch essentially did was remove all but the most top level window from the window hierarchy so commonly used in Microsoft Windows. In Windows, every window (visible and otherwise) usually is associated with a window class, a string that loosely identifies what the window does. Experience having worked with a screen reader vendor for 8 years, however, has shown that this can also be quite bogus stuff. In the dark ages of Windows development, where there was virtually nothing else than screen scraping and some basic MSAA, this was the most reliable way for screen readers and other software to identify certain parts of the UI of an application.

However, times are better now, and have essentially been, since Firefox 3.0. There, we already knew that this removal of several window widgets with associated class names, would be upon us one day. So we started evangelizing with screen reader vendors to use newer, more future-proof methods of finding our accessibility information. But as time went by, this somehow got lost by the sideways, and suddenly, August 27, 2010, was upon us.

This was the day when Bug 130078 landed on the Mozilla-Central Mercurial repository. The August 28 nightly build was broken for all screen readers on Windows. Subsequently, I filed Bug 591874. In addition, the landing of Bug 589529 made things even worse for some of the screen readers, since now, no focus events or such were processed at all any more.

This, and David’s alert blog post, shook up assistive technology vendors, open-source and commercial alike, enough so they started to tell us what kept them from using the newer methods, or what additional things they’d require to be able to work without relying on the Windows widget information any more. Subsequently, Bug 592913 was filed, which, when fixed, did get NVDA back in working order. With some adjustments on their end, which are included in the recent NVDA 2010.2Beta1 release, they are now able to work with both Firefox 3.x that still has the window hierarchy, and also Firefox 4, which has the newer method for them to get all the information they need.

A second bug, Bug 594413 is going to land very soon, which should give all those assistive technologies still primarily using iSimpleDOM to also get all the required information without having to rely on Windows widgets.

As a fall-out from the above fixes, we had to deal with Bug 594775 and some fall-out from that as well, but believe we now have most things in order again. Most, if not all of this will be in Beta7, so the user experience should again be much better than it was in beta 5 and 6, and users can again experiment with the newest and greatest Firefox beta versions.

Also, the above quoted bug 591874 is fixed now, giving select older versions of commercial assistive technologies the benefit of an emulated window hierarchy, so users do not need to upgrade their screen readers at a fee to be able to use Firefox 4. However, it must be stated that this is not going to be there forever, so we strongly recommend that software that still relies on this window hierarchy use the better and more reliable methods to detect our accessible tree and get away from using things like MozillaContentWindowClass to rely on. We now turn this emulation on only for some commercial screen reader vendor versions, but strongly suggest to also backport the new solutions to older existing user bases as soon as possible. It will go away, but we haven’t decided yet when exactly that will be.

Talk to us, we’ll be glad to assist you!


5 thoughts on “What’s up with all those windows?

  1. How to get Sidebar HWND in FF4.0?

    I have a addon that have a sidebar created using VC++. For FF4.0 there is only one window(with class name MozillaWindowClass) when checked with Spy++. We do find window to reach the sidebar panel and set that as parent of sidebar pages built in Win32.

    I tried getting the sidebar handle. I tried sending sidebar object from JS to CPP. Sidebar object is of type nsIDOMXULElement. I tried getting HWND directly from this, but couldn’t get it. I added one more function that uses nsIAccessibleDocument:: GetWindowHandle method. I converted nsIDOMXULElement to nsIDOMDocument. But when I query to get the nsIAccessibleDocument interface pointer, I don’t get it. It returns NULL.

    I also tried getting nsIBaseWindow pointer from nsIDOMXULElement, but that also fails.

    I tried sending sidebar window object from JS to CPP and then took the handle of that window.The handle that I get is of browser window. It opened sidebar in whole browser window.

    So the problem is how to get the sidebar window object in FF4.0


  2. @Paddy: This is quite involved for a simple blog comment. Please ask your question in the mozilla.dev.platform newsgroup or the original bug that introduced the widget removal. I’m not sure the developers of this feature read my blog, much less follow comments to my blog posts, and this is too involved for me, sorry!


  3. This blog post is somewhat older, but maybe you answer nevertheless 😉

    Is the described change the reason why in fx 4 beta12 the window is not accessible via the jaws cursor? I admit its not necessary very often, but sometimes it is.
    and moreover, how can one track the status of a page loading, the command for reading the bottom line of course stopped working as well.

    Is there a location more suitable for discussing such things than this comment section? I would be interested in helping to raise the accessibility of fx if I can.

    regards, Martin


Share your thoughts

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.