282588 - MozillaContentWindowClass on frames and iframes confuses screen readers

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Aaron Leventhal]

Screen readers use the class name MozillaContentWindowClass to activate their
virtual browsing modes. Since this class name is also used on frames and
iframes, the virtual browsing mode is restarted as the user navigates into the
sub document.  Instead, it should treat the frame or iframe as another piece of
content in the same flow.

Comment 1

[Aaron Leventhal]

Attachment: Use MozillaContentFrameWindowClass for frames and iframes. Please ignore IME part of patch, it's bleedover from bug 279816. I will ensure a proper merge after that fix goes in.

Comment 2

[Ere Maijala (slow)]

Comment on attachment 174582 [details] [diff] [review]
Use MozillaContentFrameWindowClass for frames and iframes. Please ignore IME part of patch, it's bleedover from bug 279816. I will ensure a proper merge after that fix goes in.

A testcase would be nice.. consider me someone very unfamiliar with screen
readers.

The patch looks technically fine. If I can test that it also works, you'll get
r=ere with this small change:

+    contentType = sameTypeParent? eContentTypeContentFrame :
eContentTypeContent;

Add a space after that question mark :)

Comment 3

[Aaron Leventhal]

Attachment: Fix space after question mark

Comment 4

[Aaron Leventhal]

Testcase is a pain -- you need a private beta of one of the screen readers. I
can't really even mention them by name because it's work that's under NDA.

Anyway, this has been par for the course. I've needed to put in a lot of fixes
based on what I've found working privately with vendors.

All of this information will be contributed to documentation at
www.mozilla.org/access such as 
http://www.mozilla.org/access/windows/at-apis

Comment 5

[Aaron Leventhal]

Ere, new patch attached for review. See my comment #4 about the testcase issue.

Comment 6

[Ere Maijala (slow)]

Comment on attachment 174612 [details] [diff] [review]
Fix space after question mark

Ok, blindfolded r=ere

Comment 7

[[e-mail]]

Comment on attachment 174612 [details] [diff] [review]
Fix space after question mark

Presumably the screen readers are unfazed by multiple chrome frames e.g. the
preferences dialog?

Comment 8

[Aaron Leventhal]

(In reply to comment #7)
> (From update of attachment 174612 [details] [diff] [review] [edit])
> Presumably the screen readers are unfazed by multiple chrome frames e.g. the
> preferences dialog?

That's correct, because they just echo focus and state changes at that point.
They don't got into a special mode for browsing web content, when they're in chrome.

Comment 9

[Aaron Leventhal]

Checking in layout/generic/nsFrameFrame.cpp;
/cvsroot/mozilla/layout/generic/nsFrameFrame.cpp,v  <--  nsFrameFrame.cpp
new revision: 3.280; previous revision: 3.279
done
Checking in widget/public/nsIWidget.h;
/cvsroot/mozilla/widget/public/nsIWidget.h,v  <--  nsIWidget.h
new revision: 3.137; previous revision: 3.136
done
Checking in widget/src/windows/nsWindow.cpp;
/cvsroot/mozilla/widget/src/windows/nsWindow.cpp,v  <--  nsWindow.cpp
new revision: 3.538; previous revision: 3.537
done
Checking in widget/src/windows/nsWindow.h;
/cvsroot/mozilla/widget/src/windows/nsWindow.h,v  <--  nsWindow.h
new revision: 3.196; previous revision: 3.195
done

Comment 10

[timeless]

hello world, did we just screw wheel mouse scrolling?

Comment 11

[Ere Maijala (slow)]

At least for me we didn't. Why?

Comment 12

[timeless]

the last few times we've played w/ window classes we broke mouse drivers. i just
want to make sure that we checked to see that we weren't doing that again.

Comment 13

[Aaron Leventhal]

(In reply to comment #12)
> the last few times we've played w/ window classes we broke mouse drivers. i just
> want to make sure that we checked to see that we weren't doing that again.

Dude! Thanks for the unneccessary panic.

We did things differently this time -- the MozillaWindowClass windows that the
drivers key on haven't changed.