:active state should stick while mouse button is pressed regardless of focus state

:active state should stick while mouse button is pressed regardless of focus state

For a css selector like 'input:active', it should match
even after focus moves out of the element.

WebKit used to clear :active flag at focus blur.

The clearing code has been there since the KHTML era but
looks irrelevant now.

BUG=365308
TEST=layout test

Committed: https://crrev.com/671b78468b2d2a3457f11dbbc5b3af23c8ad7bff
Cr-Commit-Position: refs/heads/master@{#383268}

[kochi, 2016-03-25 07:05:06]

Description was changed from

==========
Do not call setActive(false) on oldFocusElement.


BUG=365308
==========

to

==========
Do not call setActive(false) on oldFocusElement.

For a css selector like 'input:active', it should also match
when its associated label element is being clicked.

The symptom of the bug report was happening
1. the form element is already focused
2. mouse down on its associated label won't activate
   the form element (:active doesn't match).

When a form element has focus and its associated label
is clicked, the focus was once reset and then set to the
form element again.  The "active" flag is set on the
form element first, then while resetting the focus the
"active" flag was cleared, and never set again.

The clearing code has been there since KHTML era but
looks redundant.

BUG=365308
TEST=layout test
==========

[kochi, 2016-03-25 07:05:06]

kochi@chromium.org changed reviewers:
+ tkent@chromium.org

[kochi, 2016-03-25 07:07:04]

Description was changed from

==========
Do not call setActive(false) on oldFocusElement.

For a css selector like 'input:active', it should also match
when its associated label element is being clicked.

The symptom of the bug report was happening
1. the form element is already focused
2. mouse down on its associated label won't activate
   the form element (:active doesn't match).

When a form element has focus and its associated label
is clicked, the focus was once reset and then set to the
form element again.  The "active" flag is set on the
form element first, then while resetting the focus the
"active" flag was cleared, and never set again.

The clearing code has been there since KHTML era but
looks redundant.

BUG=365308
TEST=layout test
==========

to

==========
Do not call setActive(false) on oldFocusElement.

For a css selector like 'input:active', it should also match
when its associated label element is being clicked.

The symptom of the bug report was happening
1. the form element is already focused
2. mouse is clicked on its associated label
3. the form element' :active doesn't match

When a form element has focus and its associated label
is clicked, the focus was once reset and then set to the
form element again.  The "active" flag is set on the
form element first, then while resetting the focus the
"active" flag was cleared, and the flag was never set again.

The clearing code has been there since KHTML era but
looks redundant now.

BUG=365308
TEST=layout test
==========

[kochi, 2016-03-25 07:07:13]

The CQ bit was checked by kochi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-25 07:07:22]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1827363003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1827363003/20001

[kochi, 2016-03-25 07:07:23]

PTAL

[tkent, 2016-03-25 07:50:41]

> When a form element has focus and its associated label
> is clicked, the focus was once reset and then set to the
> form element again. 

Do other browsers have the same bahavior?

In the following scenario, :active should remain, or should be cleared?
 1. Press a mouse button on a focusable element (do not release the mouse
button)
    -> focused, and active
 2. Press TAB key
    -> Focus is moved.

[kochi, 2016-03-25 08:14:52]

On 2016/03/25 07:50:41, tkent wrote:
> > When a form element has focus and its associated label
> > is clicked, the focus was once reset and then set to the
> > form element again. 
> 
> Do other browsers have the same bahavior?
> 
> In the following scenario, :active should remain, or should be cleared?
>  1. Press a mouse button on a focusable element (do not release the mouse
> button)
>     -> focused, and active
>  2. Press TAB key
>     -> Focus is moved.

:active should active only while the mouse button is pressed, therefore
focus state is irrelevant.

http://jsbin.com/sikafiliti/1/edit?html,js,output
There are 2 <input>s, and while mouse is pressed the background
turns red.  Hitting TAB to move focus doesn't change if the mouse
button continues to be pressed.  I confirmed Firefox behaves this way.

[commit-bot: I haz the power, 2016-03-25 08:15:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-25 08:15:57]

Dry run: This issue passed the CQ dry run.

[kochi, 2016-03-25 08:31:06]

Description was changed from

==========
Do not call setActive(false) on oldFocusElement.

For a css selector like 'input:active', it should also match
when its associated label element is being clicked.

The symptom of the bug report was happening
1. the form element is already focused
2. mouse is clicked on its associated label
3. the form element' :active doesn't match

When a form element has focus and its associated label
is clicked, the focus was once reset and then set to the
form element again.  The "active" flag is set on the
form element first, then while resetting the focus the
"active" flag was cleared, and the flag was never set again.

The clearing code has been there since KHTML era but
looks redundant now.

BUG=365308
TEST=layout test
==========

to

==========
:active state should stick while mouse button is pressed regardless of focus
state

For a css selector like 'input:active', it should match
even after focus moves out of the element.

WebKit used to clear :active flag at focus blur.

The clearing code has been there since the KHTML era but
looks irrelevant now.

BUG=365308
TEST=layout test
==========

[kochi, 2016-03-25 08:32:02]

As we talked offline, this issue is not specific to
label and its associated element, so I changed the
description and the layout test accordingly.

The behavior is confirmed also on IE12 and Edge.

Please take another look.

[tkent, 2016-03-25 08:33:13]

lgtm

https://codereview.chromium.org/1827363003/diff/40001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/fast/css/active-pseudo-and-focus-move.html
(right):

https://codereview.chromium.org/1827363003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/css/active-pseudo-and-focus-move.html:14:
var i1 = document.querySelector('#i1');
indentation looks ugly.

[kochi, 2016-03-25 08:34:21]

On 2016/03/25 08:32:02, kochi wrote:
> The behavior is confirmed also on IE12 and Edge.

Err, IE11.

[kochi, 2016-03-25 08:43:51]

Thanks for the review.

https://codereview.chromium.org/1827363003/diff/40001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/fast/css/active-pseudo-and-focus-move.html
(right):

https://codereview.chromium.org/1827363003/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/css/active-pseudo-and-focus-move.html:14:
var i1 = document.querySelector('#i1');
On 2016/03/25 08:33:13, tkent wrote:
> indentation looks ugly.

Oops, hard TAB sneaked in.  Fixed.
(also swapped test() and if() order, as the test
doesn't make any sense without eventSender)

[kochi, 2016-03-25 09:13:24]

The CQ bit was checked by kochi@chromium.org

[kochi, 2016-03-25 09:13:24]

The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org
Link to the patchset: https://codereview.chromium.org/1827363003/#ps60001
(title: "fix indentation (TAB)")

[commit-bot: I haz the power, 2016-03-25 09:13:37]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1827363003/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1827363003/60001

[commit-bot: I haz the power, 2016-03-25 10:20:53]

Description was changed from

==========
:active state should stick while mouse button is pressed regardless of focus
state

For a css selector like 'input:active', it should match
even after focus moves out of the element.

WebKit used to clear :active flag at focus blur.

The clearing code has been there since the KHTML era but
looks irrelevant now.

BUG=365308
TEST=layout test
==========

to

==========
:active state should stick while mouse button is pressed regardless of focus
state

For a css selector like 'input:active', it should match
even after focus moves out of the element.

WebKit used to clear :active flag at focus blur.

The clearing code has been there since the KHTML era but
looks irrelevant now.

BUG=365308
TEST=layout test
==========

[commit-bot: I haz the power, 2016-03-25 10:20:54]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-03-25 10:21:53]

Description was changed from

==========
:active state should stick while mouse button is pressed regardless of focus
state

For a css selector like 'input:active', it should match
even after focus moves out of the element.

WebKit used to clear :active flag at focus blur.

The clearing code has been there since the KHTML era but
looks irrelevant now.

BUG=365308
TEST=layout test
==========

to

==========
:active state should stick while mouse button is pressed regardless of focus
state

For a css selector like 'input:active', it should match
even after focus moves out of the element.

WebKit used to clear :active flag at focus blur.

The clearing code has been there since the KHTML era but
looks irrelevant now.

BUG=365308
TEST=layout test

Committed: https://crrev.com/671b78468b2d2a3457f11dbbc5b3af23c8ad7bff
Cr-Commit-Position: refs/heads/master@{#383268}
==========

[commit-bot: I haz the power, 2016-03-25 10:21:54]

Patchset 4 (id:??) landed as
https://crrev.com/671b78468b2d2a3457f11dbbc5b3af23c8ad7bff
Cr-Commit-Position: refs/heads/master@{#383268}