288875 - input not focused inside a label containing two input controls

Status: RESOLVED WORKSFORME

(Core :: Layout: Form Controls, defect)

Description

[Brad Fults]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

See http://xkr.us/bugs/moz-05-001.html

Reproducible: Always

Steps to Reproduce:
1. View the URL [ http://xkr.us/bugs/moz-05-001.html ]
2. Click inside the text box to give it focus.
3. Click away from the text box to take away its focus.
4. Click the left mouse button down when over the Submit control, but drag your
mouse away from the control before releasing it so as not to submit the form.
5. Notice that the input field has a blinking caret in it, but does not have
focus (you can't type into the field).


Expected Results:  
The input should receive focus on mousedown (as per the behavior of the browser
address bar and other widgets). Although the spec clearly states that only one
form control should be inside a LABEL, there should be better error-handling
behavior than this. Currently the control doesn't receive focus, but rather just
a blinking caret.

Comment 1

[Hermann Schwab]

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050329

Comment 2

[Kevin Brosnan]

WFM - Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050401 Firefox/1.0+

Comment 3

[Brad Fults]

I don't know if you guys aren't following the steps correctly or what, but I can
reproduce this every time.

I am confirming the same behavior with:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050402
Firefox/1.0.3

In fact, it's worse on this Mac build. The blinking cursor is persistent across
all pages now--it never goes away until I actually close the window/tab. Please
try to follow the steps more carefully and notice that after the last step,
typing on your keyboard does not insert text into the field (as should be the
behavior).

Comment 4

[Hermann Schwab]

(In reply to comment #3)
> I don't know if you guys aren't following the steps correctly or what, but I can
> reproduce this every time.

Of course you can, there is no doubt about that after reading your detailed
description. We were simply testing if your bug seen on a Mac BRANCH build is
also seen on TRUNK builds on Linux and Windows.
So what can be said is that that problem isn´t seen on the TRUNK in other OS.
What can´t be said is that this trunk isn´t seen on the BRANCH in other OS, this
wasn´t tested.

Confirming bug on
Mozilla/5.0 (Windows; U; Win98; de-DE; rv:1.7.6) Gecko/20050321 Firefox/1.0.2

so seems to be a branch bug on all OS.

Comment 5

[Hermann Schwab]

(In reply to comment #4)

> What can´t be said is that this trunk isn´t seen on the BRANCH in other OS, this
> wasn´t tested.

When I wrote this, I was just looking at the last comment ;-)
Of course the bug was filed for Windows.

Brad, can you please attach your testcase here, so it doesn´t get lost on your
server?

Use the 'Create A New Attachment' link above, or this
https://bugzilla.mozilla.org/attachment.cgi?bugid=288875&action=enter

Comment 6

[Boris Zbarsky [:bzbarsky]]

We're not touching focus on the branch unless there's a major security exploit
involved.  Marking worskforme (since it works on trunk).