Closed Bug 242820 Opened 20 years ago Closed 19 years ago

closing sidebar with focus doesn't restore focus to page

Categories

(Firefox :: Disability Access, defect, P2)

Product:
Firefox
Component:
Disability Access
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: sophia, Assigned: aaronlev)

References

(Blocks 1 open bug)

Details

(Keywords: access, helpwanted) 

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040506 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040506 Firefox/0.8.0+

When I close an open sidebar with a keyboard command (like Cmd-B for bookmarks
or Cmd-shift-H for history), Firefox keyboard accessibility goes into a bad
state.  Or more specically, basically no keyboard control works anymore.  I
can't do any application commands or tabbing/typing navigation, nothing works,
the app does not respond.  The only thing that I have found that works is to
Cmd-~ repeatedly to toggle through any open windows (including a weird invisible
window) until I'm back to the first window.  Then after doing that, keyboard
accessibility works again.

Reproducible: Always
Steps to Reproduce:
1.  Open a sidebar (bookmarks or history).
2.  Close the sidebar with the appropriate key command.
3.  Try to do anything else with your keyboard now.
Actual Results:  
keyboard control is ineffectual

Expected Results:  
keyboard control should still work
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: access
OS: MacOS X → All
Hardware: Macintosh → All
Summary: closing a sidebar ruins keyboard accessibility → closing sidebar with focus doesn't restore focus to page
WFM.

- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040717
Firefox/0.9.1+
- Microsoft Windows 2000 Pro 5.00.2195 SP4
I can repro this on Mac (2004072711-0.9) but not on linux (2004072908-0.9),
perhaps specific to Mac firefox?

-> accessibility
Assignee: firefox → aaronleventhal
Component: General → Accessibility
QA Contact: bugzilla
Blocks: firekey
Keywords: sec508
Priority: -- → P1
Priority: P1 → P2
I can reproduce this bug in Linux (Mozilla/5.0 (X11; U; Linux i586; en-US;
rv:1.7.5) Gecko/20041103 Firefox/1.0RC2, and the latest nightly built trunk of
firefox).

When the sidebar is closed the focus still seems to remain in the sidebar  and
the currently visible tab next to the sidebar has lost the focus.

It doesn't matter if the sidebar is closed with the mouse or with the keyboard.

Keyboard control inside the visible tab is always ineffectual after closing the
sidebar. I'll have to use the mouse and click somewhere inside of the page to
give it the focus again.
This bug is not fixed yet. I still can reproduce loosing focus on Linux *and
Windows* with the latest nightly built trunk of ff.
Flags: blocking-aviary1.1?
Keywords: helpwanted
Firefox trunk build on linux (gtk2), it works fine.  closing the sidebar gives
focus to the web page and alt-f opens the file menu correctly.

Can anyone reproduce this on latest trunk builds and post exact reproducable steps?
Please open at least a webpage in one tab. Then open a sidebar and middle click
on a link inside of the sidebar to open a new tab. Then close the sidebar and go
back to the other tab. It has lost the focus and you cannot scroll with the
keyboard - on Windows, Linux and likely on the Mac.
Agree with last comment:
Alt+F will work whether the content area has focus or not.
The best way to see if the content area has focus is to check whether arrow keys
scroll the page.
I can restore the focus with Alt+F. But it is still an annoying bug that the tab
loses focus at all.
cnn.com is open
open history
open a page in a new tab from history
close history
webpage has focus
switch to cnn.com tab
indeed, focus is in the old document.

That is reproducable steps :)
Cool, this is indeed WFM with Doron's steps in a build from 2/21/05
Version: unspecified → Trunk
this also w4m using recent trunk ffox bits on mac.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
What do you mean with w4m? Can you reproduce the bug or can you not reproduce
the bug?

This bug is still reproducable on every release and the latest trunks of ff and
is not fixed/resolved and never was.
Then post exact steps to reproduce.
You already posted reproducible steps in your comment (comment #9). What's the
problem?

I will quote these steps again, with additional comments to make sure they are
executed correctly.


   1. cnn.com is open
   2. open history
   3. open a page in a new tab from history (USING THE MIDDLE MOUSE BUTTON)
   4. close history
   5. webpage has focus
   6. switch to cnn.com tab

   indeed, focus is in the old document.

   That is reproducable steps :)
   
As you know, the effect of this bug is that you cannot scroll using the keyboard
in the webpage (here cnn.com).

These steps can still be used to reproduce the bug, even in the latest "nightly
trunks".
indeed, my steps still work, so this bug shouldn't have been closed.  Note you
should switch tabs using ctrl-pageup/pagedown, as clicking on a tab gives it focus.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
This bug is fixed now in the latest trunk of ff from March 10, 2005. Perfect :-)
reporter: can you verify?
Works for me.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050317
Firefox/1.0+
The general bug described in the initial bug report is now fixed. Comment #9 and
#14 are new steps that are a different problem than the original general problem
that was fixed.

Reporter or Doron, if a combination of using history, the middle mouse button to
open documents in a new tab, and tab switch causes a problem, then that should
be filed as a separate bug. I suggest the title "Opening history in new tab can
lead to broken focus"
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WORKSFORME
Flags: blocking-aviary1.1?
You need to log in before you can comment on or make changes to this bug.