jquery.byteLimit: Rewrite (fix bug 38158, bug 38163)
authorTimo Tijhof <ttijhof@wikimedia.org>
Fri, 14 Sep 2012 02:09:47 +0000 (04:09 +0200)
committerTimo Tijhof <ttijhof@wikimedia.org>
Tue, 2 Oct 2012 02:54:48 +0000 (04:54 +0200)
commite85ff41468eae17267fe3979c0bcd54fd2f8f0a2
treec78162669a3d7693bbc2753ecbd62564b87897f2
parentbf219783efec0500cb940b0391ef9d3fc800cb31
jquery.byteLimit: Rewrite (fix bug 38158, bug 38163)

It used to be fairly simply and that seemed good enough. Listen
on keypress, get current value, add character from key code in
event object, and calculate the byteLength. If it is too long,
preventDefault().

However there were so many edge cases (too many of them to be
considered edge cases) where this failed whereas the native
maxLength handling was fine.

For example:
 - Cut and paste
 - Selecting text and replacing or removing it (by any of the
   methods on this list)
 - Custom javascript input methods (e.g. Narayam)
 - Spelling suggestions and corrections
 - Drag and drop
 - etc.

Now it acts on changes after the fact.

I considered building in a timeout loop in addition to this so
that when javascript gadgets change the input value it would
detect it, however I'd like to hold that off for now. We can
add that later if needed. For now scripts are expected to fire
the 'change' event if they change it, which seems reasonable.

The only challenge that it creates, however, is the need for
basic history reconstruction. Figure out what was already there
and what is new, and cut down the new part until the total sum
satisfies the limit.

This is the same behavior that WebKit browsers (and others) have.
e.g. of "barbaz" is pasted between "f" and "o" in "foo" with a
maxLength of 5, then the resulting string will be "fbaoo".

Also fixed bug 38158 while at it. Filed an upstream bug against
webkit/Chrome but was wont fixed. Either way, we'd have to be
compatible for a little while with old WebKit builds out there
(iOS 3, Safari 5, etc.).
http://code.google.com/p/chromium/issues/detail?id=136004

Use removeAttribute('maxlength') to let the browser internally
reset the maxLength property. Resetting it directly (to undefined
or with `delete el.maxLength') does not work and casts it to 0,
which blocks the input field entirely.

Updated unit tests, and also removed the "type=text" code
afterwards which that doesn't work in IE (Internet Explorer does
not support dynamic changing of input types), needs to be in the
HTML directly. So far it was passing in IE because 'text' is the
default. Tests now use attr('maxlength') everywhere for
consistency, though properties work the same. Browsers
synchronize these things (just like the "class" attribute and
"className" property).

References:
* Fixes bug 38158: Unexpected 0 maxLength.
* Fixes bug 38163: Incorrect limiting of input when using input
  methods other than basic per-char typing.
* Follows-up: 39cb0c19
* Supersedes: I70d09aae

Change-Id: I9c204243d0bdf7158aa86a62b591ce717a36fe27
RELEASE-NOTES-1.20
resources/jquery/jquery.byteLimit.js
tests/qunit/suites/resources/jquery/jquery.byteLimit.test.js