12422 - [Win32] Mozilla doesn't expose keyboard focus (eg to screen magnifier)

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, enhancement, P1)

Description

[cpratt]

Build ID: 1999082008 (M10 build)
Platform: Windows 98 (this bug has to do with Windows-specific features)

To reproduce:
- If you don't have the Windows 98 Accessibility tools installed, install them
using the Add/Remove Programs control panel. (Hint: If you don't have the CD
available, and are a Netscape employee, our licensed copy is at
\\surge\dist\os\win98 .)
- In the Start menu, select Programs | Accessories | Accessibility | Magnifier
to open the Magnifier Settings. The default settings are acceptable.
- Launch apprunner.
- Watch as the DOS window correctly shows in the Magnifier part of your screen;
note that as it exposes keyboard focus to Windows 98, the currently 'active'
line is in the center of the Magnifier window. This is a decent example of what
Magnifier should do.
- Wait for the main browser window to finish loading. Make sure that it is the
frontmost (active) window.
- Move the cursor somewhere away from apprunner.
- Press Alt-F to drop down the file menu.

Result: In the Magnifier window, focus is not switched to where you are
currently navigating using the keyboard, allowing you to see what you're doing.

Expected result: Apprunner should expose keyboard focus, allowing accessibility
tools for the disabled to work with Apprunner.

Comment 1

[rubydoo123]

what's the status of this bug? which milestone is this slotted for?

Comment 2

[joki (gone)]

Saari, hate to dump a bug on you but you seem better able to fix this one than I 
currently, given your recent focus and menu work.

Comment 3

[saari (gone)]

Wow. Um, okay... So how does one "expose" focus on Windows? Do I need to be 
generating events and giving them to the default proc? This is going to be tricky 
at best since the keyboard menu navigation is done via a capturing listener, and 
focus isn't really there in any way shape or form. We may have to add keyboard 
focus memory.

Comment 4

[saari (gone)]

I'm moving this to M17 if only because I don't have the first clue of how to 
proceed with it. Someone will probably push back.

Comment 5

[Peter Trudelle]

Mass moving M17 bugs to M18

Comment 6

[Jan Carpenter]

I think what he means by "exposing keyboard focus" is that when as in his 
example you hit Alt + F, the magnifier window should show you what is now active 
which is the top item on the file menu.  Currently what it shows you is some 
"random" place on the screen; often but not always wherever the mouse it.

I believe the bug here is that the magnifier doesn't follow the active areas of 
the screen when you use the keyboard.  Note in the above example that if you 
arrow down through the menu, the magnifier doesn't follow you as it should.

Comment 7

[Peter Trudelle]

mass-moving all bugs to m21 that are not dofood+, or nsbeta2+

Comment 8

[ckritzer (gone)]

Mass update:  changing qacontact to [e-mail]

Comment 9

[Loco]

Updating QA Contact.

Comment 10

[timeless]

I suppose that means I should hunt through msdn or borland's help for the
function to hint to the os what we're doing.

Comment 11

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 12

[Peter Trudelle]

Sounds like part of the accessiblity work that should be solved by implementing
the MSAA server. ->evaughan, p1 enhancement for moz0.9, cc aaron, hyatt, saari,
self

Comment 13

[Peter Trudelle]

->moz0.9.1

Comment 14

[Eric Vaughan]

This is being implemented as a part of accessibility feature

Comment 15

[Aaron Leventhal]

John's bug now.

Comment 16

[John Gaunt (redfive)]

fixed for embedding need to complete for xul

Comment 17

[Jesse Ruderman]

Does Mozilla have a way to find out where on the screen the focused element is?
See also bug 81723, keyboard context menu should open near focused item.

Comment 18

[saari (gone)]

You can ask the focus controller what the currently focused element is, and then
find its primary frame and work back up the frame and view trees to determine
wherer you are. Gross eh?

Comment 19

[Madhur Bhatia]

QA contact updated

Comment 20

[Aaron Leventhal]

Once XUL accessibility bug 82207 is fixed, this is fixed.

Comment 21

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 22

[Aaron Leventhal]

Any remaining focus issues are part of our active accessibility meta bug 82207