bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

css :focus class not properly reset/removed if switching focus away

VERIFIED DUPLICATE of bug 54820

Status

()

Core
Layout: Form Controls
P4
normal
VERIFIED DUPLICATE of bug 54820
18 years ago
17 years ago

People

(Reporter: Matthias Kerkhoff, Assigned: saari (gone))

Tracking

({css2, helpwanted})

Trunk
mozilla1.0
x86
Windows NT
css2, helpwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-])

(Reporter)

Description

18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.73 [en] (WinNT; U)
BuildID:    2000071320

If a form control A has the focus and it's switch away to a control B in another 
frame, the control A still retains its membership in the :focus class.

Reproducible: Always
Steps to Reproduce:
1. Create to frames with forms and controls in them
2. Set a :focus property (I've used background-color)
3. switch the focus between the controls.

Actual Results:  The resulting visual representation indicates, that one control 
per frame is ready for input. 		

Expected Results:  Only one control should be in :focus. Lets assume, the 
controls are text-inputs. 
The css-spec states "The :focus pseudo-class applies while an element has the 
focus (accepts keyboard events or other forms of text input).". 
Not only that only one control has the focus, it's also impossible for the user 
to enter text in more than one control (w/o switching between the frames). 
Furthermore it's inconsistent with the event model. Switching focus from control 
A to B across frame borders _will_ generate DOM/JavaScript focus and blur 
events.

As always, this is just an opinion and it may be wrong.
(Reporter)

Updated

18 years ago
Keywords: css2
(Reporter)

Comment 1

18 years ago
Some more examples...
Szenario: Two frames, one with two groups of checkboxes, one with edit controls.
1. Check one of the checkboxes of group 1
2. Move the mouse away from it - it will get the focus outline
3. Move the mouse over the checkbox again (it will come into :hover)
4. Move the mouse away from it - it be/retain in :focus
5. Now click in one of the edit controls (the checkbox will keep its focus 
outline
6. Move the mouse over the selected checkbox, don't click. It will now loose 
:focus. (ERROR, why now?)
(Reporter)

Comment 2

18 years ago
Oops. Commited too early. 
The reverse szenario leads to the same problem (edit controls also loose :focus, 
if mouse is moved over them after a similar procedure as described above).

Comment 3

18 years ago
Chris, this seems like it would be yours.
Assignee: rods → saari
(Reporter)

Comment 4

18 years ago
May be related to #42553.
(Assignee)

Comment 5

18 years ago
correctness, nominating nsbeta3
Keywords: nsbeta3

Comment 6

18 years ago
nsbeta3-, not a big problem for NS6 apps, but should have for standards.  low
priority, helpwanted.
Keywords: helpwanted
Priority: P3 → P4
Whiteboard: [nsbeta3-]
Target Milestone: --- → M18

Comment 7

18 years ago
Updating QA contact.
QA Contact: ckritzer → bsharma
(Assignee)

Comment 8

18 years ago
mozilla 1.0
Status: NEW → ASSIGNED
Target Milestone: M18 → mozilla1.0

Comment 9

18 years ago
QA Contact Update
QA Contact: bsharma → vladimire

Comment 10

17 years ago

*** This bug has been marked as a duplicate of 54820 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE

Comment 11

17 years ago
verifying duplicate, this is fixed...
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.