Bug 118043

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.