Bug 195836 - <label> with nested <input>s always focuses the first input when clicking other inputs
Summary: <label> with nested <input>s always focuses the first input when clicking oth...
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: Safari 11
Hardware: Mac macOS 10.14
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2019-03-15 17:01 PDT by JC Franco
Modified: 2023-05-25 11:38 PDT (History)
7 users (show)

See Also:


Attachments
Simple HTML that renders a form with a label with multiple inputs (560 bytes, text/html)
2019-03-15 17:01 PDT, JC Franco
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description JC Franco 2019-03-15 17:01:32 PDT
Created attachment 364882 [details]
Simple HTML that renders a form with a label with multiple inputs

Test case (attached too): https://codepen.io/jcfranco-the-scripter/pen/NJYQem?editors=1000

To reproduce, click on the time input and see how the date field gets focus.

Tested on: 

Safari - Version 12.0.1 (14606.2.104.1.1)
Safari Tech Preview - Release 77 (Safari 12.2, WebKit 14608.1.7.3)
Comment 1 Radar WebKit Bug Importer 2019-03-16 12:07:31 PDT
<rdar://problem/48955176>
Comment 2 Curtis Wilcox 2020-04-06 05:30:58 PDT
Multiple inputs as children of a single label element is not valid HTML. Run the test case through https://validator.w3.org/nu/ and one of the errors will be "The label element may contain at most one button, input, meter, output, progress, select, or textarea descendant."

The WHATWG spec document doesn't describe only one such child element as valid, it says "If the for attribute is not specified, but the label element has a labelable element descendant, then the first such descendant in tree order is the label element's labeled control." That matches the behavior you describe.

https://html.spec.whatwg.org/multipage/forms.html#the-label-element
Comment 3 Ahmad Saleem 2023-05-25 11:38:44 PDT
I am not able to reproduce this bug using attached testcase and all browsers allow you to place caret in 'time' field without any jumpy etc.

Safari 16.5, STP170, Chrome Canary 115 and Firefox Nightly 115 have same behavior.

Marking this as 'RESOLVED CONFIGURATION CHANGED".