Closed Bug 166501 Opened 22 years ago Closed 21 years ago

focus "lost" (not obvious) when switching windows from Window menu

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

defect
Not set
normal

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: bugzilla, Assigned: bryner)

References

(Blocks 1 open bug)

Details

(Keywords: topembed, Whiteboard: [adt2])

found using bryner's test (mozilla trunk) build. this kind of reminds me of bug
153681, in that i need to hit the tab key in order to gain focus into a window's
content area. couldn't quite find an existing bug for this, but pls do dup if
needed.

test A: two browser windows
---------------------------
1. have two browser windows opened. for example, window (a) pointing to
http://www.iwaruna.com/orca/food/index.html and window (b) pointing to
http://mozilla.org. (it doesn't matter, afaict, if there are multiple tabs present.)

2. make sure focus is in the content area of window (a).

3. in window (a), select the menu item Window > mozilla.org to switch to window (b).

4. window (b) comes to the foreground. now, try see where focus is, and try to
scroll using the keyboard (spacebar, pageUp/Down, etc).

results: there's no focus ring visible. also unable to scroll using the
keyboard. workaround: if i hit the tab key twice (like bug 153681) to
move/display focus in the content area of window (b).


test B: one browser window and an editor window
-----------------------------------------------
1. have two windows opened, where window (a) is the browser pointing to
http://mozilla.org and window (b) is an editor window.

2. make sure focus is in the content area of window (a).

3. in window (a), select the menu item Window > [title of editor window] to
switch to the editor window (b).

4. window (b) comes to the foreground. now, try see where focus is, and try to
scroll using the keyboard (pageUp/Down) or start typing.

results: the caret in the editor window is not visible. also unable to scroll,
or start typing immediately. workaround: if i hit the tab key once, a focus ring
appears in the content area, the cursor appears and i'm able to start typing in
the doc.


test C: one browser window and a mailnews window
------------------------------------------------
1. have two windows opened, where window (a) is the browser pointing to
http://mozilla.org and window (b) is the mailnews 3pane window.

2. make sure focus is in the message pane of (b).

3. switch focus to the browser window (a).

4. in window (a), select the menu item Window > [inbox of mailnews window] to
switch to the mailnews window (b).

5. window (b) comes to the foreground. now, try see where focus is, and try to
scroll using the keyboard (spacebar, arrow keys, pageUp/Down, etc).

results: there's no visible focus ring in any of the panes of the mailnews
window. also unable to scroll. workaround: if i hit the tab key once, a focus
ring appears in the folder pane. NOTE: if focus was initially in the folder OR
thread panes at step (2), then this case is NOT a problem.
nominating for buffy.
Keywords: nsbeta1
Just wanting to double-check, are you saying this problem only appears in my
test build, or it also appears in trunk builds without my patch?
oops, forgot to mention that i also see this in nscp7.0rtm (branch) bits, so i
don't think it's a regression due to your 141295/153681 fix. just checked a
regular trunk build (2002.09.04.08, linux comm), and it's a problem there as well...
Blocks: focusnav
also occurs on win2k and mac os x (10.1.5).
OS: Linux → All
Hardware: PC → All
adt: nsbeta1+/adt2
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt2]
Keywords: topembed
I just tested all of these cases on WinXP (today's nightly build) and they all
work as expected.  This was probably fixed by some of my recent checkins. 
Marking WORKSFORME.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Oops, that was me, not dbaron.  dbaron was using bugzilla on my machine and
didn't log out.
the three scenarios also w4m; tested with 2003.05.15 comm builds.
Status: RESOLVED → VERIFIED
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.