bakemall.jp - Items are overlapped (relies on magic <input type=number> min / max sizing behavior).
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
People
(Reporter: azlata, Assigned: emilio)
References
()
Details
Attachments
(4 files, 2 obsolete files)
Environment:
Operating system: Windows 10
Firefox version: Firefox 126.0/128.0a1 (2024-05-21)
Steps to reproduce:
- Access https://bakemall.jp/store/aab71dcd-c00a-4eb7-a22b-4a48c2f603a1?date=2024-05-30T07%3A00%3A00%2B09%3A00
- You might be prompted to choose a date
- scroll through the page
- Try to add items
Expected Behavior:
The quantities of the items can be changed without issues.
Actual Behavior:
The characters, buttons and fields for entering quantities all overlap, making it impossible to input correctly.
Notes:
- Reproduces regardless of the status of ETP
- Reproduces in Firefox Nightly, Firefox Release
- Does not reproduce in Chrome
Created from https://github.com/webcompat/web-bugs/issues/137268
Reporter | ||
Updated•4 months ago
|
Reporter | ||
Comment 1•4 months ago
|
||
![]() |
||
Updated•4 months ago
|
Comment 2•4 months ago
|
||
Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Assignee | ||
Comment 6•3 months ago
|
||
This is just about the auto size of the number
input, apparently... Chrome seems to do something where the min
/ max
values influence the auto size, somehow?
Assignee | ||
Comment 7•3 months ago
|
||
Chrome behaves the same as Firefox if I remove the min=""
and max=""
attributes... Ugh
Assignee | ||
Comment 8•3 months ago
|
||
WebKit logic is here.
Blink is here, which looks basically the same (so, probably comes from WebKit).
Assignee | ||
Comment 9•3 months ago
|
||
I filed https://github.com/whatwg/html/issues/10390 with a proposal.
Assignee | ||
Updated•3 months ago
|
Assignee | ||
Comment 10•3 months ago
|
||
See https://github.com/whatwg/html/issues/10390 for the spec issue.
Updated•3 months ago
|
Comment 11•3 months ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/cd09151a1c46 Implement min/max-derived sizing for <input type=number>. r=smaug
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/46632 for changes under testing/web-platform/tests
Comment 13•3 months ago
|
||
Backed out for causing OS X wpt failures in transform-input-014.html.
- Backout link
- Push with failures
- Failure Log
- Failure line: TEST-UNEXPECTED-FAIL | /css/css-transforms/transform-input-014.html | Testing http://web-platform.test:8000/css/css-transforms/transform-input-014.html == http://web-platform.test:8000/css/css-transforms/transform-input-014-ref.html
Upstream PR was closed without merging
Updated•3 months ago
|
Comment 15•3 months ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/7fdc398eba16 Implement min/max-derived sizing for <input type=number>. r=smaug
Comment 16•3 months ago
|
||
bugherder |
Assignee | ||
Updated•3 months ago
|
Upstream PR merged by moz-wptsync-bot
Upstream PR merged by moz-wptsync-bot
Comment 19•3 months ago
|
||
The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox127
towontfix
.
For more information, please visit BugBot documentation.
Assignee | ||
Comment 20•3 months ago
|
||
This is a long-standing bug so probably not worth uplifting.
Updated•3 months ago
|
Updated•3 months ago
|
Comment 21•2 months ago
|
||
Reproducible on a 2024-05-22 Nightly build on Windows 10.
Verified as fixed on Firefox 128.0 and Firefox Nightly 129.0a1 on Windows 10, Ubuntu 22, macOS 14.
Description
•