Closed Bug 218995 Opened 21 years ago Closed 20 years ago

accesskeys only half-focus page textboxes if address bar has focus

Categories

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

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jruderman, Assigned: mikepinkerton)

References

Details

(Keywords: access, regression)

Steps to reproduce:
1. Make http://www.cs.hmc.edu/~jruderma/s/ your home page.
2. Ctrl+T.
3. Alt+Home.
4. Alt+1.
5. Start typing into the Google box.

Result: Text typed at step 5 doesn't appear in the textbox, even though a
blinking caret appears in the textbox.  Strangely, Ctrl+V still works.

The important thing is that the address bar is focused when the page loads. 
Here's a series of steps to reproduce that doesn't involve the Home Page and
Tabbed Browsing features:
1. Load http://www.cs.hmc.edu/~jruderma/s/.
2. Click a link.
3. Click the address bar.
4. Alt+left.
5. Alt+1.
6. Start typing into the Google box.

This bug happens in Firebird 09/11 and Firebird 09/10 but not in Firebird 09/09.
 Seamonkey 09/11 also shows this bug, so it's not Firebird-specific.

I only see one focus-related checkin on 09/09: bug 198153, "Tabbing from
Location Bar to content requires two or more tab presses".  The checkin comment
was "check if there is an active focus controller before sending the blur".
Backing out the checking from bug 198153 fixes this bug.  The patch in 198153
isn't what was checked in, so I tested with

cvs update -r 1.454 nsEventStateManager.cpp
sigh. jesse, can you back it out for me?
I wonder if someone could look at the accesskey code? The patch that caused this
regression was reviewed by several people and without it, we're back to the
tabbing callbacks not working for embedding browsers.
Pinkerton: I think my CVS account isn't still active, so I can't back your patch
out of CVS for you.  (Do you need a= to back out a patch from the branch?)

Nathan: If you change how accesskeys focus things, see if your changes also fix
bug 180638 and bug 129889.
Blocks: focusblink
I have a problem which I believe may be related to this.

I have the following preference set:
accessibility.tabfocus = 3
so that I don't have to tab through links, just form elements.

When I open a bookmark folder using "Open in tabs" in the latest firefox (2004
May 3) and also version 0.8, the following behavior occurs:

My first tab is set to the Yahoo login page.  The caret is flashing in the
"Yahoo! ID" prompt, but if I try to type, nothing appears.  I can press <tab>
multiple times until finally I get to the NEXT textbox (password, not the yahoo
id) and then I can shift-<tab> back to the yahoo id.

The weird thing is that this bug happens when I first open firefox and "open in
tabs", but NOT if I "open new window" and then try the above in the new window.
 The bug also seems to not appear if the "accessibility.tabfocus" is not set to
3, but to its default.
Does the fix for bug 241942 make this bug work?
WFM firefox 07/17 and seamonkey 06/30.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.