Watch out! Chrome has a huge bug with <input type="number"> which causes values to change unexpectedly. It's fixed in Chrome 150, but that won't land until the end of June.

The 'fixed' behaviour in Chrome 150 is screwy too: Default: mouse wheel doesn't change the input value. Allows scrolling. If there's a non-passive 'wheel' listener on any parent: wheel does change the value. Prevents scrolling. If there's a passive listener: The bug returns.

Some are saying this isn't new… but it is. For a long time, if there's a parent element with a non-passive wheel listener (which React adds by default) then the wheel changes the input value, but it doesn't also scroll the page. The bug I'm talking about is different & new.

The bug I'm talking about results in the input changing as well as scrolling, making it way more likely that the user doesn't notice the change - as in the video. - the bug appeared in Chrome 147, and was fixed in 150.

Yesssss @bramus got the fix merged into Chrome 149, which rolls out next week. The bug's still there if you have a passive "wheel" listener on any parent, but hopefully that's less common.

is this a bug ??? 😅 I thought i just need to focus away and then scroll 😂

Yes, this doesn't happen in Firefox or Safari. It was a regression in Chrome 147

That bug has been there for years hasn’t it. Swear I’ve seen it for a long time, so long as that input field is focused

Nah it depends on listeners

how is something like this not a hotfix candidate, especially given it's a regression from the previous version 🤯

I'm pushing for it to be a hotfix. Fingers crossed.

I face this issue regularly - it's amplified when you use the Logi Master mouse, because it keeps spinning 🫠

Thank you for flagging this! We were wondering why people were all of a sudden donating amounts like $1,000.07 at the nonprofit I work at.

I guess you should put the submit button at the top so people have to scroll up to get to it. Increased donations!

I think it's just new feature, scroll driven inputs!

I thought that was a new feature. Now I have to add it back.

@firefox on top babyyyyyyy!!!!

Jake, come on, dude, please don't vibe code chrome 😂

This behavior isn’t exactly new, is it? Chrome has worked like this for many years. What surprises me more is that this is apparently a regression :)

Some time ago, Chrome would use the scroll wheel for changing values in number inputs, but it wouldn't scroll the page at the same time. All of that is bad UX. The scroll wheel shouldn't change values.

@pjchrobak no in a number input field with arrows it's totally the expected behavior imo and i hate programs that don't implement it

@pjchrobak ok. i disagree. especially when it comes to the page scrolling at the same time.

is it really bug? seen this in other browsers like brave

Brave uses the same engine as Chrome, so they share bugs like this. Some time ago, Chrome would use the scroll wheel for changing values in number inputs, but it wouldn't scroll the page at the same time. All of that is bad UX. The scroll wheel shouldn't change values.

@pranav_222000 When was this bug introduced? Personally I didn't have a big problem with scroll wheel incrementing / decrementing. A little unexpected but "The control has focus, so... yeah, OK". Does (page)up/down do the same thing? For "consistency"?

@pranav_222000 It's the combination of scrolling the input & scrolling the page at the same time that's the worst of both worlds. See the demo in the video. This regressed in Chrome 147.

the workaround's been stable for years. type=text + inputmode=numeric, or onWheel blur on focus. wheel still bites type=number even after 150 if a passive listener exists. which crbug tracks it?

I suffered from this bug

u think overscroll contain could work in this case ? 🤔 it could stop the page from scrolling when u scroll inside the input which will give u the chance to see that the input's value has changed

I've posted a workaround to

also - trying to reproduce here but without success Version 148.0.7778.179 (Official Build) (arm64)

this is a bug? feel like its been like this for a while

Nah. If there's a parent element with a non-passive wheel listener (which React adds by default), then Chromium would change the input on wheel scroll, but it'd prevent element scroll too. This bug is fresh and new for Chrome 147.

time to watch @uwukko on his way to fix it in helium as soon as possible

How did they even cause this ? Did they remove the condition that checks if i'm hovering the input ?

Its a bug??? I always had that and I fixed it by doing on scroll: blur

I guess you use React, which always adds a wheel listener, so it hits the second behaviour here

Might be a feature in a very rare use-cases.

in cases where you want the user to order the wrong number of things maybe

That could be a funny use-case but not for users & customers though.

Anything devs can do to prevent end user exposure to this bug? Just don’t use type=number?

There's a hacky fix, but it isn't ideal

Thanks for the info. I'll test it out.

Is there any workaround short of removing type=number until Chrome 150 lands at the end of June?

I never use type=number because I've always felt it induces error. I think It's one of those cases where the user never gets used to and would rather haver a simpler behavior. Like mailto links or having to pick birth date on a type=date input.

Is the solution then to unfocus the input and then scroll?

yep, tell all your users to do that I guess

How to replicate? It only inc/decriments when focussed AND on hover for me. No focus = no change.

It's getting focus in the video. That's how I'm able to type in the input.

I wonder how bugs like this even make its way in. Any insights into the Chrome engine code that caused this bug @jaffathecake ?

It was caused by a commit that worked on overlay scrollbar fade-outs. But the root of the problem is Chrome having weird logic around when it does and doesn't activate the "scroll wheel changes number inputs" behaviour.

this issue is there for years. I am also focusing somewhere first before scrolling the page. just in case ...

i don't think it's a bug it's a feature that i always disable when creating inputs

It's a bug

This isn't new.... Been around since forever

it's new

Just googled this & seemed like there is a way to disable that using JavaScript. if(document.activeElement.type === "number"){ document.activeElement.blur(); } Haven’t tried it myself though. Here is where the same question was asked.

Ah, how many times I had cursed this behavior… So they’re removing the mousewheel event completely from affecting these inputs?