335668 - Highlighted search result can not be displayed in magnified screen automatically.

Status: RESOLVED DUPLICATE of bug 371273

(Firefox :: Disability Access, defect)

Description

[Tim Miao]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050607 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050607 Firefox/1.0.4

Magnifier works in half screen magnification mode. Search result can be highlighted in source screen, but it failed to trace these search result in magnified screen automatically.

Reproducible: Always

Steps to Reproduce:
1. Launch firefox and load a web page, say http://www.mozilla.org/ .
2. Launch gnopernicus-magnifier.
3. Press Ctrl+F to open the "Find" toolbar, input one word in text field, say 'mozilla', then click "Find Next" button.

Actual Results:  
Search result can be highlighted in source screen, but in magnified screen, it fails to trace the highlighted search result no matter you click the button or press Alt+N.

Expected Results:  
Search result should be dynamic traced and displayed in magnified screen.

This bug can be found on vermillion_39/snv_38.

Comment 1

[Aaron Leventhal]

Are we firing selection change events?

Comment 2

[Evan Yan]

(In reply to comment #1)
> Are we firing selection change events?
> 
As my investigating, no selection change event was fired.

There are 2 line of commented code in nsCaretAccessible::NotifySelectionChanged(), which does somthing with firing selection change event. see
http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsCaretAccessible.cpp#232

Ginn provided a patch for bug 312093, which also did something about this bug.

Comment 3

[Ginn Chen]

(In reply to comment #1)
> Are we firing selection change events?
> 

I don't know if gnome magnifier uses this event for tracing.

Comment 4

[Aaron Leventhal]

How else would it track search results in applications?

Comment 5

[Ginn Chen]

The problem of this bug is when clicking "Find Next" or pressing "Enter/F3", caret is still inside the "Find" textbox.
Press "Esc", gnome magnifier will trace to the highlighted item, because caret is there.

Comment 6

[Aaron Leventhal]

The old style find as you type from Seamonkey would not have this problem. I'm not sure if Seamonkey uses the findbar now. Anyway, there may be a way in about:config to turn the findbar off.

Otherwise, I'm not sure how the magnifier would know. Focus does need to be in that textbox.

Any ideas? Do we need to add something to ATK/AT-SPI?

Comment 7

[Ginn Chen]

Simple workaround:

1) Ctrl+F, type what you want to find, Press Esc
(alternately, you can turn on typeaheadfind, and just type in.)
2) Use F3 to find next.

Can we close this bug as WONTFIX or WORKSFORME?

Comment 8

[Aaron Leventhal]

Ginn, it's not an ideal solution. Ideally the magnifier would track where the search result is because that's more important to the low vision user than where they're typing. People are also not going to discover the Escape key trick easily.

I think another solution might be to turn off the findbar and use oldstyle find as you type. People also will not easily discover that unless magnifier does it for them automatically somehow, by setting a Firefox pref.

I'd like to hear other opinions on it.

Comment 9

[Aaron Leventhal]

Ginn, how about we mark the document as controlledbby the textfield, and then ask that magnifier be changed to respect selection change events for a document that is controlled by something that is focused?

Or is that too much work for the AT?

Comment 10

[Ginn Chen]

I'm not familiar with gnopernicus-magnifier.
We need a developer of gnopernicus-magnifier to make sure it can work.

Comment 11

[timeless]

note that the windows magnifier lets the user *choose* what to follow, which probably means windows users aren't as unfortunate as users of whichever clever magnifier is being used here.

Comment 12

[Aaron Leventhal]

(In reply to comment #11)
> note that the windows magnifier lets the user *choose* what to follow, which
> probably means windows users aren't as unfortunate as users of whichever clever
> magnifier is being used here.

Sorry Timeless, not that simple. MSAA doesn't have any good event for selection changes.

Comment 13

[Aaron Leventhal]

IAccessible2 has selection move events.

Comment 14

[Aaron Leventhal]

We now fire selection move events in both IA2 and AT-SPI when the find bar is open. This was fixed via bug 371273.

If there is still a problem with any magnifier it's a bug in the magnifier software at this point.