Closed Bug 379368 Opened 17 years ago Closed 17 years ago

Window-Eyes no longer speaks the current character as you arrow through input field

Categories

(Core :: Disability Access APIs, defect)

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

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: deangelo, Assigned: aaronlev)

References

(
URL
)

Details

(Keywords: access, regression) 

Env: FF3 Minefield nightly build 20070501, Window-Eyes release 6.1

Problem: Window-Eyes no longer speaks the current character or speaks the incorrect character.

NOTE: This is a regression, I have verified that this problem was introduced on nightly build date of 5/11/2006.

Steps to recreate:

1. Start Window-Eyes and Firefox 3.
2. Focus on the URL combo box and type www.ebay.com
3. Tab through the www.ebay.com with the left arrow and you will notice that either Window-Eyes will miss speaking a character or two....or speak the wrong character.
Actually since builds didn't run from 5/11 - 5/15 the regression could have been any time in there.



Checkins between 2006-05-10 06:00 and 2006-05-16 10:00

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-10+06%3A00%3A00&maxdate=2006-05-16+10%3A00%3A00&cvsroot=%2Fcvsroot

Might be one of these:
bug 336590, bug 336679
(In reply to comment #1)
> Actually since builds didn't run from 5/11 - 5/15 the regression could have
> been any time in there.
> 
> 
> 
> Checkins between 2006-05-10 06:00 and 2006-05-16 10:00
> 
> http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-10+06%3A00%3A00&maxdate=2006-05-16+10%3A00%3A00&cvsroot=%2Fcvsroot
> 
> Might be one of these:
> bug 336590, bug 336679
> 

Update, Yes between 5/11 and 5/15 these build would install BUT will not run without a quick crash, that means that the problem reported could be from any change between 5/11 and 5/16.
Wasn't those. Backing them out doesn't fix it.
I notice that in Firefox 2 (where the bug doesn't occur), that as the caret blinks over a letter, it reverses the pixels (so the black pixels from the letter become white). In current trunk builds, I see that it just sets it all to black.
You can see this more easily if you set your screen resolution to 800x600. Then just go to the URL bar and hit Home to set your caret on the "h" of "http". You can then see whether the vertical line in the "h" becomes white or stays black.

Does this difference occur between the the 5/10 and 5/16 builds?
I don't think the regression range is correct.

For me it's:
Works in 2-1-2006
Broken on 4-7-2006

I'll check again tomorrow when I'm not burnt out.
Another observation: as I arrow through, about half the time a character from 2 places to the right is reported.
Works in 2-1-2006
Broken 3-1-2006. Also, as you arrow over the characters they half-disappear, so it's fair enough that they don't get spoken.
Works in 2-15-2006
Broken in 2-21-2006
Let me correct that. Here is the regression range that I found:
2-22 works
2-23 broken

In 2/23 there is some apparent visual rendering change in the address bar, where there is more spacing between the characters, especially around the /'s
In 2/23 the caret wipes pixels out as it's drawn over characters.
Blocks: keya11y
I think this is the change:
2006-02-22 20:05	pavlov%pavlov.net 	mozilla/configure.in 	1.1619 	1/1  	Build with the thebes gfx backend by default on Windows. bug 323923. r=vlad sr=roc. 

That would be no surprise. It turns on Cairo by default for Windows builds.
Fixed via bug 381888 -- see remaining issues listed there.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.