300642 - Fastback regression: screen readers can't load pages

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Aaron Leventhal]

Load Window-Eyes or another screen reader with Firefox.

Navigate to a new page.

The screen reader does not see the text for the new page.

This regressed in the June 29 build, and was caused by the enablement of
fastback (bug 298293).

Comment 1

[Aaron Leventhal]

Attachment: Turn off fastback when windows screen reader is present. Temporary fix until we understand the fastback architecture and develop the right long term solution

Does the fastback pref work on-the-fly or is a restart required?

Comment 2

[Aaron Leventhal]

Interesting clues:
1. The screen reader can see the content for the first page that loads into the
browser
2. If you hit Ctrl+R to reload the current page, the screen reader can then load
the content after the reload finishes.

Comment 3

[Brian Ryner (not reading)]

It seems like the likely culprit is that there may be multiple windows with that
class now.  If screen readers can't deal with that, perhaps we should remove the
window class when hiding the page and restore it when showing the page.

Comment 4

[Aaron Leventhal]

(In reply to comment #3)
> It seems like the likely culprit is that there may be multiple windows with that
> class now.  If screen readers can't deal with that, perhaps we should remove the
> window class when hiding the page and restore it when showing the page.

Or maybe we can just forward WM_GETOBJECT requests to the appropriate window.

Here's the window structure I'm seeing now:
MozillaContentWindowClass
   MozillaWindowClass    (scrollbar window)
       MozillaWindowClass   (client area window) --> has the accessible info
   MozillaWindowClass    (hidden scrollbar window)
       MozillaWindowClass   (hidden client area window)

It used to be that the MozillaContentWindowClass had only 1 child. Is this correct?

Comment 5

[Aaron Leventhal]

Attachment: 1) Use active window for root accessible that we return, 2) don't cache accessible root since we already cache it elsewhere

Comment 6

[Aaron Leventhal]

This fix will allow things to work as they used to. 

* If WM_GETOBJECT is on the MozillaContentWindowClass it will find the active
child window and return the info for that. In the past that was the only child.
Now it requests an accessible from presshell and receives null if the
corresponding presshell is not the current one (it checks by looking for a
docshell on that).
* If WM_GETOBJECT is on the child MozillaWindowClass of that window, it acts as
before and and gets the accessible from the corresponding presshell.

Also I removed the extra caching of root accessible on nsWindow because it would
require a depth first window search to clear it out, and it isn't necessary now
that we cache accessibles in the accessibility module on a per DOM node basis.

Comment 7

[Aaron Leventhal]

Checking in layout/base/nsPresShell.cpp;
/cvsroot/mozilla/layout/base/nsPresShell.cpp,v  <--  nsPresShell.cpp
new revision: 3.844; previous revision: 3.843
done
Checking in widget/src/windows/nsWindow.cpp;
/cvsroot/mozilla/widget/src/windows/nsWindow.cpp,v  <--  nsWindow.cpp
new revision: 3.563; previous revision: 3.562
done
Checking in widget/src/windows/nsWindow.h;
/cvsroot/mozilla/widget/src/windows/nsWindow.h,v  <--  nsWindow.h
new revision: 3.204; previous revision: 3.203
done

Comment 8

[Boris Zbarsky [:bzbarsky]]

Note that the mContainer member of prescontext really needs to go away, so it'd
be good if we could find some other way to do this... :(

Comment 9

[Aaron Leventhal]

(In reply to comment #8)
> Note that the mContainer member of prescontext really needs to go away, so it'd
> be good if we could find some other way to do this... :(

We probably need something more self-documenting. Who would know that if a
presshell didn't have a docshell that it's in the bfcache but not active?

How about nsIPresShell::IsCachedInactive() or something so people can find it?

Comment 10

[Boris Zbarsky [:bzbarsky]]

Sounds like a good idea to me.  Then the impl can check mContainer on the
prescontext for now and do something else if we nuke mContainer.

Comment 11

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381