317213 - magnification loses focus of text element and moves to the top of the application

Status: RESOLVED FIXED

(Firefox :: Disability Access, defect)

Description

[Jason Grieves]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051010 Firefox/1.0.7 (Ubuntu package 1.0.7)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051010 Firefox/1.0.7 (Ubuntu package 1.0.7)

When using Full Screen or Split Screen magnificatoin with Zoomtext on Windows or Gnopernicus magnifier on Linux when entering text in any field the focus is brought to the top corner of the application.  This was tested with the latest Gnopernicus and Zoomtext with both FF 1.5 and 1.0.7

Reproducible: Always

Steps to Reproduce:
1.open up www.google.com
2.open up magnifier
3.begin typing in a text box
4.you must move the mouse to bring focus back

Actual Results:  
focus moves to the top left corner of the screen

Expected Results:  
focus of magnifier moves with the application

This occurs with multiple elements, I tried turning on caret browsing for kicks and experienced same results.  I was unable to find this bug anywhere else, though I am sure it is here.  Could you create another category for Accessibility?  

Now low vision users who use magnifiers can use Firefox.  Just imagine if every time you began typing in your application it instantly went to the top of the page.  This is critical for low vision accessibility.

Comment 1

[Reed Loden [:reed]]

(In reply to comment #0)
> Could you create another category for Accessibility?  

We have a "Disability Access" component that this would fall under. Moved to it.

Comment 2

[Ginn Chen]

Like a dupe of bug 172674

Comment 3

[Evan Yan]

Attachment: deal with the situation when there is no text to get

this bug is caused by two things:
1. In nsMaiInterfaceText.cpp:getCharacterExtentsCB, it should be "if(!accText)" but not "if(accText)". This has been fix by some patch from Ginn Chen for another bug.
2. When user deleted all the text in a text box, nsAccessibleText::GetCharacterExtents() will end with error, Which the attached patch deals with.

Comment 4

[Jason Grieves]

(In reply to comment #3)

Thanks so much!  This bug does a much better job keeping up with me.  However as I type this bug in this box, it does not bring hte focus back correctly when it reaches the end of a line.  Instead it appears to out of bounds and loses focus completely.  The product is much more usable however to the gnome-mag screen magnifier.

> Created an attachment (id=205718) [edit]
> deal with the situation when there is no text to get
> 
> this bug is caused by two things:
> 1. In nsMaiInterfaceText.cpp:getCharacterExtentsCB, it should be "if(!accText)"
> but not "if(accText)". This has been fix by some patch from Ginn Chen for
> another bug.
> 2. When user deleted all the text in a text box,
> nsAccessibleText::GetCharacterExtents() will end with error, Which the attached
> patch deals with.
> 

Comment 5

[Evan Yan]

I think that is another bug. And I filed bug 320357 for that.

(In reply to comment #4)
> Thanks so much!  This bug does a much better job keeping up with me.  However
> as I type this bug in this box, it does not bring hte focus back correctly when
> it reaches the end of a line.  Instead it appears to out of bounds and loses
> focus completely.  The product is much more usable however to the gnome-mag
> screen magnifier.
> 

Comment 6

[Aaron Leventhal]

How can this fix anything for ZoomText if the patch is only in the atk directory? That's not built for Windows.

Comment 7

[Evan Yan]

In fact, I have tested the bug under windows, and can reproduce it.

User Agent:      Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Comment 8

[Evan Yan]

sorry for the typo.
I can NOT reproduce the bug under windows.

(In reply to comment #7)
> In fact, I have tested the bug under windows, and can reproduce it.
> 
> User Agent:      Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8)
> Gecko/20051111 Firefox/1.5
> 

Comment 9

[Ginn Chen]

Jason, can reproduce this bug with latest trunk and Zoomtext on Windows?

Comment 10

[Ginn Chen]

Checking in nsAccessibleText.cpp;
/cvsroot/mozilla/accessible/src/atk/nsAccessibleText.cpp,v  <--  nsAccessibleText.cpp
new revision: 1.26; previous revision: 1.25
done

Comment 11

[Jason Grieves]

(In reply to comment #9)
> Jason, can reproduce this bug with latest trunk and Zoomtext on Windows?
> 
I believe this is fixed in the latest trunk and latest Zoomtext.  I have contacted a fellow Zoomtext user who will open a new bug if he experienced any other problems.

Thanks for the fix!  

Comment 12

[Ginn Chen]

Comment on attachment 205718 [details] [diff] [review]
deal with the situation when there is no text to get

Firefox is unusable with gnome magnifier when trying to inputs something.

Risk is low.

See also Bug 317482

Comment 13

[Ginn Chen]

Checking in src/atk/nsAccessibleText.cpp;
/cvsroot/mozilla/accessible/src/atk/nsAccessibleText.cpp,v  <--  nsAccessibleText.cpp
new revision: 1.24.8.1; previous revision: 1.24
done