118043 2013-06-26 00:02:12 -0700 Mouse press should focus on any types of form controls 2021-05-17 02:52:07 -0700 1 1 1 Unclassified WebKit Forms 528+ (Nightly build) Unspecified Unspecified RESOLVED DUPLICATE 22261 BlinkMergeCandidate P2 Normal --- 1 rniwa webkit-unassigned allan.jensen ap gsnedders jmjacobs jonlee lizmitchell priyajeet.hora redux syoichi tkent oldest_to_newest 903573 0 rniwa 2013-06-26 00:02:12 -0700 Consider merging https://chromium.googlesource.com/chromium/blink/+/b9834f34667cd0a4bee67fe702a915950dfb839a * Background In WebKit, form controls except text fields and <select> are not mouse-focusable. This behavior is based on Cocoa native controls. Though Firefox on Mac behaves same as WebKit, IE, Firefox (non-Mac), and Opera(Presto) set focus by mouse press. The WebKit behavior is not Web-compatible. * Behavior change We change the behavior so that mouse press sets focus to form controls to improve web compatibility. However, We haven't set focus until now and this behavior change might make existing users uncomfortable with focus rings which appear on click. So, we don't draw focus rings if a form control was focused by mouse press. * Implementation The main part of this CL is to remove HTMLFormControlElement::isMouseFocusable. It means we use Node::isMouseFocusable, which is just isFocusable. We can remove many isMouseFocusable implementations of HTMLFormControlElement subclasses. We change the followings to hide focus rings on mouse-focus: - Introduce FocusDirectionMouse so that form control can distinguish mouse focus from others. - HTMLFormControlElement has m_wasFocusedByMouse flag. It is cleared when a keydown event is delivered. - Introduce HTMLFormControlElement::shouldShowFocusRingOnMouseFocus, which represents differences between button controls and text/select controls. - RenderTheme, RenderObject, RenderInline don't draw focus rings if conditions match. We introduced Node::willCallDefaultEventHandler to re-show focus rings after keyboard operations. Test changes: - Add many tests for new behavior. - Remove fast/events/click-focus-control.html because now it is covered by existing and new tests. - Need rebaseline for afast/repaint/slider-thumb-float.html. We show a focus ring for a control without -webkit-appearance. 916490 1 rniwa 2013-08-12 19:18:09 -0700 Also merge https://chromium.googlesource.com/chromium/blink/+/543428b511b8fa108a740d2f707b10490dae20db 916766 2 ap 2013-08-13 09:56:23 -0700 I’m pretty sure we have something to dupe this to. 922619 3 rniwa 2013-08-29 13:06:44 -0700 Also see https://chromium.googlesource.com/chromium/blink/+/de021e8f7e23817680c5e1c3bfae93cda4556e27 923109 4 ap 2013-08-30 11:38:18 -0700 > I’m pretty sure we have something to dupe this to. And that something likely has a long discussion about why this is not desirable. 948128 5 rniwa 2013-11-07 01:12:26 -0800 Another regression fix: http://src.chromium.org/viewvc/blink?revision=153039&view=revision 948129 6 rniwa 2013-11-07 01:12:36 -0800 (In reply to comment #5) > Another regression fix: http://src.chromium.org/viewvc/blink?revision=153039&view=revision I mean https://chromium.googlesource.com/chromium/blink/+/ae238642883fd96e5ad4fa019ea13187dab4f5ae 948422 7 tkent 2013-11-07 14:25:44 -0800 (In reply to comment #6) > (In reply to comment #5) > I mean https://chromium.googlesource.com/chromium/blink/+/ae238642883fd96e5ad4fa019ea13187dab4f5ae I recommend to merge Blink r159400 regardless of this bug. Blink r159400 is a general improvement of LABEL processing. 1677223 8 redux 2020-08-02 11:33:11 -0700 Coming in late as this caught me by complete surprise today ... that clicking with a mouse on a <button> does not set focus/fire the focus event on the <button>. This feels...extremely broken and unexpected. I understand the rationale may be to "avoid visual clutter" (per https://bugs.webkit.org/show_bug.cgi?id=26856) but this sounds like an odd reason to break a fairly basic assumption on events/behavior. Also, this is likely a dupe of https://bugs.webkit.org/show_bug.cgi?id=26856 ? 1677224 9 redux 2020-08-02 12:08:17 -0700 and probably related too https://bugs.webkit.org/show_bug.cgi?id=112968 1677225 10 redux 2020-08-02 12:11:17 -0700 and https://bugs.webkit.org/show_bug.cgi?id=92029 (sorry for flood of comments, but only unearthed these just now, as it seems to be a long-standing decision not to focus things) 1760703 11 gsnedders 2021-05-17 02:52:07 -0700 (In reply to Patrick H. Lauke from comment #8) > Coming in late as this caught me by complete surprise today ... that > clicking with a mouse on a <button> does not set focus/fire the focus event > on the <button>. This feels...extremely broken and unexpected. > > I understand the rationale may be to "avoid visual clutter" (per > https://bugs.webkit.org/show_bug.cgi?id=26856) but this sounds like an odd > reason to break a fairly basic assumption on events/behavior. FWIW, I wouldn't take the opinion of a former Chrome engineer over a decade ago to have any bearing on WebKit today. As discussed in bug 22261, Safari follows the macOS setting that controls whether non-text inputs are focusable, so that behaviour is similar between native apps and the web. But yes, let's close this as a dupe. *** This bug has been marked as a duplicate of bug 22261 ***