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.
what's the status of this bug? which milestone is this slotted for?
Summary: [PP] Win32 - Apprunner doesn't expose keyboard focus → Win32 - Apprunner doesn't expose keyboard focus
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.
Assignee: joki → saari
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.
Status: NEW → ASSIGNED
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.
Target Milestone: M15 → M17
Mass moving M17 bugs to M18
Target Milestone: M17 → M18
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.
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
Mass update: changing qacontact to email@example.com
QA Contact: janc → ckritzer
Updating QA Contact.
QA Contact: ckritzer → lorca
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.
Whiteboard: [need info]
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
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
Assignee: saari → evaughan
Severity: major → enhancement
Status: ASSIGNED → NEW
Priority: P3 → P1
Target Milestone: Future → mozilla0.9
Target Milestone: mozilla0.9 → mozilla0.9.1
This is being implemented as a part of accessibility feature
Status: NEW → ASSIGNED
Whiteboard: [need info] → accessibility
John's bug now.
Assignee: evaughan → jgaunt
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.1 → mozilla0.9.2
fixed for embedding need to complete for xul
Target Milestone: mozilla0.9.2 → mozilla1.0
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.
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?
QA contact updated
QA Contact: gerardok → madhur
Summary: [Win32] Mozilla doesn't expose keyboard focus → [Win32] Mozilla doesn't expose keyboard focus (eg to screen magnifier)
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)
Target Milestone: mozilla1.0 → mozilla1.0.1
Any remaining focus issues are part of our active accessibility meta bug 82207
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.