Closed Bug 390670 Opened 17 years ago Closed 17 years ago

Gecko not Rendering GMail Site to MSAA

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: tkeenan, Assigned: aaronlev)

References

(
URL
)

Details

(Keywords: access) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007080204 Minefield/3.0a7pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007080204 Minefield/3.0a7pre

I receive nothing in Jaws and the following in Window-eyes:
wyciwyg://0/http://mail.google.com/mail/?view=page&name=js&ver=1t6ksswaq6lz2



Reproducible: Always

Steps to Reproduce:
1. Open www.gmail.com
2. Sign in.

3.
Actual Results:  
Buffer is empty or contains one line.

Expected Results:  
Should at least see the html elements of the page.
Any idea when this regressed?
Assignee: nobody → aaronleventhal
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
It might be one of those internal crashes that MSAA so inconveniently swallows.

I wonder if it works with Orca.
This sounds like it might be caused by bug 255820, given the wyciwyg changes it made and the URL you`re seeing in Window-eyes (see also bug 390168).
Tim, you could check if it breaks that day.
Aaron, I'm not sure what you mean.
Also, the site:
http://citeseer.ist.psu.edu/464827.html

has the same problem, except this time nothing is spoken in Window-eyes or Jaws.  Note that you are able to review the site with the mouse cursor of each screen-reader, but it's not loading into the buffer.
Severity: normal → major
Flags: blocking1.9?
Keywords: access, sec508
Tim, that's useful to have 2 examples.

What I was asking if you could figure out what day it broke. That'd be super helpful.
I have the info:
2007-07-05 works
2007-07-06 broken

I believe this was caused by bug 377783.

It works now. I think Ginn's fix in bug 387347 fixed it. He made my empty frame check so it only occurs on table caption frames, which is much last drastic.

Tim, please verify that it works again in nightly builds for you.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Flags: blocking1.9?
You need to log in before you can comment on or make changes to this bug.