Closed Bug 335668 Opened 15 years ago Closed 13 years ago

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

Categories

(Firefox :: Disability Access, defect)

Sun
OpenSolaris
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 371273

People

(Reporter: tim.miao, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access)

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.
Keywords: access
OS: Other → Opensolaris
Hardware: Other → Sun
Are we firing selection change events?
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
(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.
(In reply to comment #1)
> Are we firing selection change events?
> 

I don't know if gnome magnifier uses this event for tracing.
Status: UNCONFIRMED → NEW
Ever confirmed: true
How else would it track search results in applications?
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.
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?
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?
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.
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?
I'm not familiar with gnopernicus-magnifier.
We need a developer of gnopernicus-magnifier to make sure it can work.
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.
(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.
Blocks: keya11y
IAccessible2 has selection move events.
Blocks: ia2
No longer blocks: keya11y
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.
Status: NEW → RESOLVED
Closed: 15 years ago13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 371273
You need to log in before you can comment on or make changes to this bug.