636976 - Undesired focus-behaviour when using TAB in a CSS-styled FORM

Status: RESOLVED DUPLICATE of bug 616594

(Core :: Disability Access APIs, defect)

Description

[Leen Besselink]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110225 Firefox/4.0b13pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110225 Firefox/4.0b13pre

The user fills in an INPUT-field and pressed tab. Instead of jumping to the next INPUT-field the focus shifts to the DIV in between the 2 INPUT-fields or the DIV around the next INPUT-field.

This seems to be caused by the extra CSS:
DIV { overflow:auto; }

Reproducible: Always

Steps to Reproduce:
1. Load testcase
2. Press tab
3. See focus change to DIV instead of next INPUT-field
Actual Results:  
When tab is pressed the focus shifts to the DIV, not the next INPUT-field.

Expected Results:  
When tab is pressed the focus should shift the next INPUT-field.

The bug has been spotted by me on several sites on the Internet (I don't remember which). I was running the nightly build at that time and thought it was just a glitch. Later I discovered this problem still existed in current beta releases.

So I don't know when that behaviour started.

I've seen this behaviour on Windows and on Linux. The testcase has been tested on Linux only.

When the DIV with the text 'Password:' is removed, the DIV around the INPUT-field is still selected instead of the INPUT-field itself.

Comment 1

[Leen Besselink]

Attachment: Test case with javascript to focus on first INPUT

Comment 2

[Alice0775 White]

Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/7b324b328cbc
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101020 Firefox/4.0b8pre ID:20101020212220
Fails:
http://hg.mozilla.org/mozilla-central/rev/93e95f4f73af
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101020 Firefox/4.0b8pre ID:20101020233524
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7b324b328cbc&tochange=93e95f4f73af
Suspected:
93e95f4f73af	Alexander Surkov — Bug 570275 - rework accessible tree update code, r=marcoz, davidb, bz, a=blocking

Comment 3

[alexander :surkov (:asurkov)]

the suspected part of bug 570275 is nsFrame::IsFocusable changes - http://hg.mozilla.org/mozilla-central/diff/93e95f4f73af/layout/generic/nsFrame.cpp

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

Sounds like nsIFrame::IsFocusable needs to check that overflow: auto is actually producing scroll bars?

IMO we wouldn't delay the amazing FF4 on this bug; but I'm marking .x+ and we'd probably approve a safe patch.

Leen, thanks for catching this and attaching a test case!

Comment 5

[Marco Zehe (:MarcoZ)]

I can confirm this on Windows with NVDA. I've never seen this on sites I visit. The good part, at least in this testcase, NVDA does speak the "password" text, so the user knows they've landed on something that is focusable. NVDA doesn't keep silent. So they can press tab again and land on the actual field.

Comment 6

[Leen Besselink]

"Leen, thanks for catching this and attaching a test case!"

No problem. It is in my own interrest. I just want it to work. :-)

I was surprised by the speed of "Alice0775 White". I ones reported a IE crashing bug at Microsoft and never heared anything at all. Eventhough crashing bugs could be possible security bugs.

But you don't have to thank me, I've already received a t-shirt from Mozilla for previous bug reports.

Anyway keep up the good work !

I'll shut up now, there is nothing I can add to this bug as I don't know anything about the Firefox code.

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

After marking this .x+ it bothered me all weekend. Marking 'blocking2.0:?'; This is a regression and it should be easily fixable. I showed Jeff this morning and he noticed there appear to be non functional scroll bars on the far right.

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

Neil what is the best way to check if there is actually a scrollbar in nsFrame::IsFocusable?

Note we might need to come back full circle on this bug. Back to:
https://bugzilla.mozilla.org/attachment.cgi?id=278819&action=diff
From:
http://hg.mozilla.org/mozilla-central/diff/93e95f4f73af/layout/generic/nsFrame.cpp

Alexander why did we need that recent change?

Comment 9

[Neil Deakin]

Elements are focusable when overflow: auto or overflow: scroll is used.

It used to be the case that the actual size of the scrollbar was used. This was changed in bug 570275. See comment 79 or so for the rationale.

The fix here is to revert that change, or just close the bug.

Comment 10

[David Bolter [:davidb] (NeedInfo me for attention)]

Found an earlier bug, I'll move relevant bits over there.

Comment 11

[alexander :surkov (:asurkov)]

(In reply to comment #8)

> Alexander why did we need that recent change?

We needed it because previous stuff in IsFocusable failed because it was called "too early" (see nsCSSFrameConstructor::ContentRangeInserted). 

Note, we don't need this change now.