(In reply to juraj.masiar from comment #3) > Note that the bug 1741469 incorrectly states that only Firefox implemented this feature - I can clearly change focused inputs with scrolling in Chrome / Edge, using Windows / Ubuntu. Can you add detail on *where* you're seeing inputs change value on scrolling? In particular, do you see the inputs changing value in testcase 1 or 2? I retested today in Chrome/Edge on Windows 11, and I confirmed those inputs are not changing value for me (as they previously were in Firefox, prior to bug 1741469). I can confirm that I do see Chrome/Edge changing the number on the website in comment 0, though (on the "refinement" number-input field in the add-weapon UI). And I do see a related Chromium bug report that mentions `onwheel` and has some clue sabout what is actually required to trigger this input-field-mutation behavior there -- apparently Chromium triggers this behavior if there's an element with `onwheel` whose hit-test region overlaps the number field, for some reason? https://issues.chromium.org/issues/40859979#comment8 Here's a testcase to demonstrate that: ``` data:text/html,<div onwheel><input type="number"></div><divl><input type="number"></div> ``` In Chrome on my Win11 machine, only the first element there has its value modified by mousewheel-scrolling.
Bug 1939377 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to juraj.masiar from comment #3) > Note that the bug 1741469 incorrectly states that only Firefox implemented this feature - I can clearly change focused inputs with scrolling in Chrome / Edge, using Windows / Ubuntu. Can you add detail on *where* you're seeing inputs change value on scrolling? In particular, do you see the inputs changing value in testcase 1 or 2? [edit: I meant testcase 1 or 2 on bug 1741469] I retested today in Chrome/Edge on Windows 11, and I confirmed the inputs in those testcases are not changing value for me (though they previously were changing when mousewheel-scrolled in Firefox, prior to bug 1741469). I can confirm that I do see Chrome/Edge changing the number on the website in comment 0, though (on the "refinement" number-input field in the add-weapon UI). And I do see a related Chromium bug report that mentions `onwheel` and has some clue sabout what is actually required to trigger this input-field-mutation behavior there -- apparently Chromium triggers this behavior if there's an element with `onwheel` whose hit-test region overlaps the number field, for some reason? https://issues.chromium.org/issues/40859979#comment8 Here's a testcase to demonstrate that: ``` data:text/html,<div onwheel><input type="number"></div><divl><input type="number"></div> ``` In Chrome on my Win11 machine, only the first element there has its value modified by mousewheel-scrolling.
(In reply to juraj.masiar from comment #3) > Note that the bug 1741469 incorrectly states that only Firefox implemented this feature - I can clearly change focused inputs with scrolling in Chrome / Edge, using Windows / Ubuntu. Can you add detail on *where* you're seeing inputs change value on scrolling? In particular, do you see the inputs changing value in testcase 1 or 2? [edit: I meant testcase 1 or 2 on bug 1741469] I retested today in Chrome/Edge on Windows 11, and I confirmed the inputs in those testcases are not changing value for me (though they previously were changing when mousewheel-scrolled in Firefox, prior to bug 1741469). I can confirm that I do see Chrome/Edge changing the number on the website in comment 0, though (on the "refinement" number-input field in the add-weapon UI). And I do see a related Chromium bug report that mentions `onwheel` and has some clues about what is actually required to trigger this input-field-mutation behavior there -- apparently Chromium triggers this behavior if there's an element with `onwheel` whose hit-test region overlaps the number field, for some reason? https://issues.chromium.org/issues/40859979#comment8 Here's a testcase to demonstrate that: ``` data:text/html,<div onwheel><input type="number"></div><divl><input type="number"></div> ``` In Chrome on my Win11 machine, only the first element there has its value modified by mousewheel-scrolling.
(In reply to juraj.masiar from comment #3) > Note that the bug 1741469 incorrectly states that only Firefox implemented this feature - I can clearly change focused inputs with scrolling in Chrome / Edge, using Windows / Ubuntu. Can you add detail on *where* you're seeing inputs change value on scrolling? In particular, do you see the inputs changing value in testcase 1 or 2? [edit: I meant testcase 1 or 2 on bug 1741469] I retested today in Chrome/Edge on Windows 11, and I confirmed the inputs in those testcases are not changing value for me (though they previously were changing when mousewheel-scrolled in Firefox, prior to bug 1741469). I can confirm that I do see Chrome/Edge changing the number on the website in comment 0, though (on the "refinement" number-input field in the add-weapon UI). And I do see a related Chromium bug report that mentions `onwheel` and has some clues about what is actually required to trigger this input-field-mutation behavior there -- apparently Chromium triggers this behavior if there's an element with `onwheel` whose hit-test region overlaps the number field, for some reason? https://issues.chromium.org/issues/40859979#comment8 Here's a testcase to demonstrate that: ``` data:text/html,<div onwheel><input type="number"></div><div><input type="number"></div> ``` In Chrome on my Win11 machine, only the first element there has its value modified by mousewheel-scrolling.