https://bugzilla.wikimedia.org/show_bug.cgi?id=29467

--- Comment #6 from Brion Vibber <[email protected]> 2011-07-11 19:19:52 UTC 
---
Additional complications testing on Firefox 5/Ubuntu 11.04:

* using Japanese input method, no keypress events fire *at all*
* using English keyboard + compose key, composed characters (eg
'compose+apostrophe', 'e' to create 'é') do not fire keypress events

In both cases, nothing stops the text from being entered until you hit the
actual maximum character count (which is enforced by the browser's widget sets)

meanwhile:
* using Japanese kana, Israeli Hebrew, or Esperanto keyboards, keypress events
do fire for keys that can be typed directly

I'm still not sure what happens on the off chance that some keyboard
configuration actually lets you type non-BOM characters directly -- does it
give you one keypress event with the full Unicode code point number, or two
(one with each surrogate character), or none like the fancy input methods?


To deal with input methods, pastes etc, we probably need to actually do the
'let it happen, then check if it was legit' method since I'm not sure we can
cleanly get the change that's about to happen before it happens.


Honestly my inclination in the long term is to deprecate these byte-limited
fields entirely:

* replace most random varchar(255)s with saner or unlimited in-db fields, and
apply sensible char limits instead of hardcoded byte limits

* where really needed for legacy issues (eg page titles), apply the limit as
part of other form field validation -- a raw byte count is insufficient in any
case then as you need to normalize before checking the length. This should
probably be asynchronous and not apply hard limits, but allow you to type in
extra crud and just whinge at you until you fix it.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to