New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 767825 link

Starred by 5 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug-Regression


Participants' hotlists:
Indispensable-for-Project-V


Sign in to add a comment

Buttons can be made look permanently pressed down

Reported by philipp....@gmail.com, Sep 22 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.18 Safari/537.36

Steps to reproduce the problem:
1. Have a button on a page (styled link does not count). See my attached example for such one.
2. Give this button focus, e.g. by using the tab key.
3. Press this button down using the keyboard by holding down the space bar.
4. Click somewhere on the page but not on the button elements (or keep the left mouse button pressed down).
5. Let go of the space bar (and the mouse button if you kept pressing it down, it's important thought that the mouse isn't above the button element).

What is the expected behavior?
The button switching back to not looking pressed down again. 

What went wrong?
The button stays styled in the pressed down state while neither mouse nor keyboard buttons are pressed down.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 62.0.3202.18  Channel: n/a
OS Version: 
Flash Version: 

The switch back could happen e.g. after triggering of the last "releasing-of" event matching any "pressing-down" event (mouseup for mouseup, keyup for keydown) representing the action which would lead to the button switching to the pressed-down state.

Note that this leaves open the question of switching focus in the case of keys and whether what to do if the mouse cursor leaves the element while being pressed down (AFAIR, the default OS behavior differ on this). If leaving the element keeps the button in the pressed down state then releasing the mouse button should make the button switch into unpressed state again no matter where the mouse button was released.
 
perma_dent.html
1.5 KB View Download
It can be also reproduced on this very page here (if you are logged in) by using the "Discard" button for this (six shift-tab presses after loading the page to give it the focus).
Labels: Needs-Triage-M62

Comment 3 Deleted

Oh and Windows is also an affected OS, not just Linux. And I wouldn't rule out macOS either.
Concerning giving the focus to a button (point 2 in the steps), instead of the tab key this is also possible through by pressing down the left mouse button with the cursor on the button but then moving it away from the button and releasing it outside.
Cc: vamshi.k...@techmahindra.com
Labels: Triaged-ET Needs-Feedback
@Reporter: Could you please have a look at the screen cast attached here, which is made by following the steps mentioned in the comment #0. And let us know is that the behavior you are seeing, as we feel it's working fine. It would be highly helpful if you update us with this in order to further triage the issue.

Thanks!  
767825.ogv
1.7 MB View Download
No, you didn't reproduce the problem since the button did not stay in the pressed-down state. It seems like you didn't keep the space key pressed down while clicking outside but I can't tell for sure since I don't see your exact key presses or clicks in the video.
Project Member

Comment 8 by sheriffbot@chromium.org, Oct 5 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "vamshi.kommuri@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 9 Deleted

Comment 10 Deleted

Cc: sc00335...@techmahindra.com
Components: Blink>HTML>Focus
Labels: -Type-Bug -Pri-2 hasbisect-per-revision M-63 OS-Mac OS-Windows Pri-1 Type-Bug-Regression
Owner: kochi@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on reported version 62.0.3202.18 and on latest canary 63.0.3237.0 using Mac 10.12.6, Ubuntu 14.04 and Windows 10 with steps mentioned in comment#0.

Good Build: 51.0.2690.0 
Bad Build: 51.0.2691.0

You are probably looking for a change made after 383267 (known good), but no later than 383268 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/9bfa2f564d21f22fa74fd0ffbefbf7c290166332..671b78468b2d2a3457f11dbbc5b3af23c8ad7bff

Review URL: https://codereview.chromium.org/1827363003

Suspecting same from Changelog.

@kochi: Please confirm the bug and help in re-assigning if it is not related to your change.

Thanks!

Comment 12 by kochi@chromium.org, Oct 13 2017

Labels: -Pri-1 Pri-2
sc00335628@ Thanks for pinpointing the issue, I'll take a look.
Even thought this is a regression introduced at my CL, the severity
isn't as serious as P1 - lowering the priority.

Comment 13 by kochi@chromium.org, Oct 17 2017

Cc: kochi@chromium.org
Owner: ----
bulk edit to remove owner=me where I'm not actively looking at.

Comment 14 by kochi@chromium.org, Oct 17 2017

Status: Available (was: Assigned)
mark it available.
Here the test case with styling applied to make the unpressed and pressed-down states more discernible.
Magic Button Styled.html
4.0 KB View Download
And here now a better recording showing the issue.

perma_dent.webm
2.6 MB View Download
Project Member

Comment 17 by sheriffbot@chromium.org, Oct 18

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: -kochi@chromium.org
Labels: -Hotlist-Recharge-Cold
Status: Available (was: Untriaged)

Sign in to add a comment