Last modified: 2012-08-16 16:45:27 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 T31804, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 29804 - jquery.byteLimit should allow the limit to be reached
jquery.byteLimit should allow the limit to be reached
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
unspecified
All All
: Normal major (vote)
: ---
Assigned To: Jan Paul Posma
:
Depends on: 29467
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-10 21:01 UTC by Krinkle
Modified: 2012-08-16 16:45 UTC (History)
6 users (show)

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


Attachments

Description Krinkle 2011-07-10 21:01:42 UTC
See also https://bugzilla.wikimedia.org/show_bug.cgi?id=28650 and r86698 in which this module was created.

r91844 added a test suite exposed a bug.

jquery.byteLimit is preventing characters to be added as soon as byteLength(currentValue) + 3 is more than the given limit.

Consider the following scenarios:

byteLimit: 10
input: "123456890123456890" (20 chars, 20 bytes)
result: 8 chars
expected: 10 chars ("1234567890")

The last 2 characters were incorrectly prevented from insertion.


byteLimit: 14
input: "1234567890€1234567890€" (22 chars, 26 bytes; contains two euro-symbols of 3 bytes each)
result: 13 chars
expected: 14 ("1234567890" + "€" + 1)

The last one was incorrectly prevented.


byteLimit: 12
input: "1234567890€1234567890€"
result: 10 chars
expected: 10 ("1234567890". as the next 3-byte "€" would exceed the limit)

This third scenario is the only one correctly passing.
Comment 1 Brion Vibber 2011-07-11 17:56:01 UTC
r91891 fixes these test cases:
* take the char code and run it through jquery.byteLength instead of hardcoding 3 (keypress gets char codes, not keycodes)
* fix for one test case that expected 10 chars but actually gets 12

Unknowns:
* how does any of this interact with native OS input methods?
* does any of this work with Narayam JS input method?
* how does keypress handle non-BOM characters? Are they reported as two events with surrogate pairs? If so this may.... explode horribly with them. ;)
* in general this keypress technique fails to handle paste and won't properly handle text selection replacement etc.
Comment 2 Krinkle 2011-07-11 19:49:59 UTC
(In reply to comment #1)
> * in general this keypress technique fails to handle paste and won't properly
> handle text selection replacement etc.

This is (also) coverered bug 29467.
Comment 3 Mark A. Hershberger 2012-01-23 15:46:28 UTC
switch to milestone, remove release tracking dep
Comment 4 Bawolff (Brian Wolff) 2012-08-15 12:43:49 UTC
>how does keypress handle non-BOM characters? Are they reported as two events
>with surrogate pairs? If so this may.... explode horribly with them. ;)

I think I tested this way back. I can't remember for sure but I think the answer was yes on some browsers.
Comment 5 Krinkle 2012-08-16 16:45:27 UTC
Marking fixed for the cases that we opened the bug for.

For more advances cases, see bug 29467 instead.

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


Navigation
Links