Last modified: 2014-10-16 11:27:17 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T72974, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 70974 - maxlength html form values are not used in preferences
maxlength html form values are not used in preferences
Status: NEW
Product: MediaWiki
Classification: Unclassified
User preferences (Other open bugs)
unspecified
All All
: Low minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 70973
  Show dependency treegraph
 
Reported: 2014-09-17 23:32 UTC by Jared Zimmerman (WMF)
Modified: 2014-10-16 11:27 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Jared Zimmerman (WMF) 2014-09-17 23:32:37 UTC
e.g. preferences -> Editing -> columns has a maximum value of "1000" and should have a maxlength="4" since any value over 1000 will cause an error. While this still does not solve for any 4 digit number greater than 1000 being entered and causing an error it will give users an idea about the scale of the number needing to be input. 

instances in prefs where this issue is present:

Editing -> columns |  maxlength="4"
Editing -> rows |  maxlength="4"

Recent changes ->Days to show in recent changes | maxlength="2"

watchlist -> Days to show in watchlist: | maxlength="2"
Comment 1 Matthew Flaschen 2014-09-18 22:57:29 UTC
input type="number" does not support maxlength (https://html.spec.whatwg.org/multipage/forms.html#concept-input-apply), since you're meant to use min/max instead (which would also address your point).

However, we currently blacklist them, since it reportedly has a bad user experience (you're blocked from submitting, but you don't know why) in some browsers.  I've opened bug 71026 so we can re-evaluate this, when either there are no "current enough" browsers with the bad behavior and/or we can polyfill it.

Other than that, the only option would be to change it from number to text, but that's a little hackish (and still doesn't solve the min/max).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links