Tested this issue using #59.0.3071.115 on Win 10 and was unable to reproduce the issue as per the steps mentioned in comment #0.

@cannon.palms.websitepipeline: Could you please find the attched screen cast and let us know if we missed any steps from our end. If possible please attach a expected screen cast for better understanding of the issue.

Thanks!!

Deleted: Jul 10 2017 3-43 AM.webm 2.1 MB

	Jul 10 2017 3-43 AM.webm 2.1 MB View Download

Yes, apologies for not being more specific. I have recorded a screencast of my own to demonstrate the issue.

https://drive.google.com/file/d/0B4X5cgbpq9VlWFJ0QkJQMXQzb0E/view

As you can see, I am able to click the "up" arrow of the input and subsequently target the "down" arrow consistently, _without_ any mouse movement.

Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

@cannon: Thanks for the detailed information.

Still no luck in reproducing the issue using #59.0.3071.115 on Win 10 as you mentioned in your screen cast.

Please find the attached screen cast and let us know your observations.

Removing Bisect label as this issue is not reproducible from our end. Please add it back if required.

Thanks!!

Deleted: Jul 10 2017 9-15 PM.webm 2.8 MB

	Jul 10 2017 9-15 PM.webm 2.8 MB View Download

It looks like you are almost there. As you click, move your cursor upwards until you are _barely_ on the edge of the top arrow. If you are too high, you will not be able to click the top arrow.

I have updated the fiddle to increase the height of the input to make it more obvious.

Here's another screencast.

https://drive.google.com/file/d/0B4X5cgbpq9VlZjhmSGgzaUNra1k/view

Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

data:text/html,<input style="font-size: 40px" min="-99" max="99" value="0" type="number" />

I can reproduce using Windows 7 and Chrome 59.

While it looks as if the decrement button is clicked when the issue occurs, it is not really clicked, because the value does not change, it is just a visual manifestation of the real issue and it also happens when try it with the decrement button (but then the visual manifestation looks the decrement button is being clicked, but the value still does not change).

Err... Missing words.
*it also happens when you try it
*looks like the decrement button

Maybe an easier example -
data:text/html,<input style="zoom: 10; font-size: 40px" min="-99" max="99" value="0" type="number" />

This is indeed a regression, as far as I can tell. Using BrowserStack -
- I cannot reproduce using Chrome 56.
- I can reproduce using Chrome 57 - 60.
Only on Windows (I tried 7 and 10), not on macOS.

I would not link the fact that it does not reproduce on macOS to https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/forms/SpinButtonElement.cpp?sq=package:chromium&l=228 though.

Tested this issue on Windows 10 with chrome #59.0.3071.115 , Canary #61.0.3154.0 with provided code in comment #8, able to reproduce the issue inconsistently.

phistuck@ could you please help us with another repro case for bisecting this issue.

Thank You....

Not really.

I think an easier step is:

1. Press the primary mouse button on the "up" button (Do not release the mouse button)
2. Move the mouse cursor up to the outside of the number input (Do not release the mouse button yet)

It seems "up button is pressed" state is cleared, but "something is pressed" state remains. 

LayoutTheme::ControlStatesForLayoutObject():

  if (IsPressed(o)) {
    result |= kPressedControlState;
    if (IsSpinUpButtonPartPressed(o))
      result |= kSpinUpControlState;
  }

Able to reproduce the issue on windows 7, Ubuntu 14.04 and Mac 10.12.6 using chrome version 59.0.3071.115 and canary 61.0.3159.0 as per the steps mentioned in comment #14.
Observed the same behaviour till M45 old builds.Hence considering this as non regression issue.

Thanks,

 Issue 763785  has been merged into this issue.

FYI, this issue shows up in Chrome's Print Preview as the Scale and Copies boxes are number inputs. See  https://crbug.com/763785 .

I have encountered and can reproduce this issue in Win 10 (1703), Chrome Version 61.0.3163.91. https://www.screencast.com/t/swzxE1JnOF 

Please note that issues 682018, 748073, 491748, and  419018  all seem to be closely related to this one, in that the increment/decrement functionality stops working in some manner after multiple clicks with a stationary cursor on a number input spinner. 

Suggestions for reproducing it:
- Click rapidly and repeatedly on the up-arrow region of the spinner with the cursor in a fixed location. At some point the value will get stuck.
- If after ~100 clicks you do not see the value get stuck, reposition the cursor slightly and resume rapid clicking.
- Try different zoom levels
- It is not strictly the case that you need to have the cursor near the top of the up arrow. I have even had value get stuck while using the down arrow, but much harder to reproduce.
- There seems to be a degree of randomness - a few brief casual attempts are not sufficient.  Sometimes it may take 100+ clicks, other times less than 10.

Hope this helps.  Thanks!

Correction: issues 682018, 748073, 491798, and  419108 all seem related

I'm very sorry for needing this second post.

Hi there... first time posting here but glad I'm not the only one who has this problem. This is still an issue in 67.0.3396.99 on Win 8.1 and is a fairly important problem in my application.

For me, the repro steps are similar to what's posted in comment 18 above:

- Click rapidly/repeatedly/steadily on a spinner button of a number input without moving the mouse (anywhere on the spinner seems to do it; it seems easier to reproduce on the up spinner for me)

- After some number of clicks, the text in the input box will highlight and the spinner will stop responding; the bottom spinner will flash as if it's being clicked

- A small mouse movement will restore correct behavior

I've been using this page for testing; click the "run code snippet" in the first post: 
https://stackoverflow.com/questions/24286506/number-input-always-show-spin-buttons

Reviewing the related issues mentioned in comment 19, issues 748073 and 419108 do look like duplicates of this bug. Interestingly, some of these bugs go back many years. From reading some of these other posts, the problem exists on many platforms and OS versions.

Anything (reasonable) I can do to move this forward?