New issue
Advanced search Search tips

Issue 337668 link

Starred by 4 users

Issue metadata

Status: WontFix
Owner:
Closed: Oct 2014
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug


Show other hotlists

Hotlists containing this issue:
Relevant-for-Bootstrap-4


Sign in to add a comment

weird input[type=number] button behavior at non-default heights

Reported by cvreb...@gmail.com, Jan 24 2014

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36

Example URL:
http://jsfiddle.net/FFXEc/

Steps to reproduce the problem:
1. Open the demo JS Fiddle in Chrome.
2. (All further instructions are regarding the second/middle input[type=number] field on the demo.)
[Bug A]:
3. Hover the cursor up and down along the inner right edge of the field, in horizontal alignment with the increment and decrement buttons.
[Bug B/C]:
4. Click on the top part of the decrement button, such that you observe normal behavior.
5. Continue clicking repeatedly while moving your cursor downward, beyond the decrement button but still within the bounds of the input field.

For some further details, see https://github.com/twbs/bootstrap/issues/8350

What is the expected behavior?
A: The cursor ought to always remain a pointer while it's within the bounds of the decrement button.
B: Clicking outside the bounds of the increment/decrement buttons should not cause the input field's value to change.
C: Invoking the decrement button should always cause it to flash blue to indicate that it was clicked.

What went wrong?
A: The cursor changes from a pointer to an "I"-bar (for text entry/selection) well before you have gone outside the bounds of the decrement button.
B: The field's number value continues to decrement.
C: The decrement button did not flash blue to indicate that it was somehow clicked.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes 

Chrome version: 32.0.1700.77  Channel: stable
OS Version: OS X 10.7.5
Flash Version: Shockwave Flash 12.0 r0

Have not tested what happens on platforms other than Mac OS X 10.7.5.

Firefox hasn't implemented input[type=number].
Safari version 6.1.1 (7537.73.11) does implement input[type=number], and only suffers from B, not A or C.
 
I can reproduce for odd-number pixel values of font-size.

Comment 2 by tkent@chromium.org, Jan 28 2014

Labels: -Cr-Content Cr-Blink-Forms

Comment 3 by tkent@chromium.org, Jan 28 2014

Status: Untriaged

Comment 4 by tkent@chromium.org, Apr 7 2014

Labels: Cr-Blink-Forms-Number
Labels: Needs-Feedback
I cannot reproduce this. Can someone make a video showing this repro?

Comment 6 by hnrc...@gmail.com, Sep 30 2014

Also unable to reproduce. A screencap showing the faulty behavior can be found here: https://github.com/necolas/normalize.css/commit/d86aa8500ee7e8c6568413ccfc115fe437010727#commitcomment-5393332

Comment 7 by cvreb...@gmail.com, Sep 30 2014

I can no longer reproduce this either (*applause to Chrome devs*), although I have discovered & reported a new related <input type="number"> bug while re-testing this:
https://code.google.com/p/chromium/issues/detail?id=419108

(Chrome 37.0.2062.124, OS X 10.9.5)

Comment 8 by cvreb...@gmail.com, Sep 30 2014

Have filed a WebKit bug since Safari still suffers from this bug:
https://bugs.webkit.org/show_bug.cgi?id=137269
Labels: -Needs-Feedback
Owner: paulir...@chromium.org
Status: WontFix
We're looking good in Blink now. Looks like it's been addressed at some point.

I can reproduce in WebKit. Thanks for filing over there.

Sign in to add a comment