r100391 MediaWiki - Code Review archive

Repository:MediaWiki
Revision:r100390‎ | r100391 | r100392 >
Date:22:50, 20 October 2011
Author:brion
Status:resolved (Comments)
Tags:
Comment:
QUnit test cases for bug 31847: will trigger a fail on IE 6/7/8

jquery.textSelection's getCaretPosition() gives bogus results on IE 6/7/8 when there's not a selection set in the textarea; it seems to give us some value somewhere in the middle of the textarea, rather than what we expected.
If we actually set an empty selection, then it gets it back just fine!
But if the cursor is in initial state, or has been moved by the user, we get back garbage. This is causing WikiEditor to sometimes insert things in the wrong place, as it tries to pull the caret position and manipulate the selection to do insertions; we then end up using the bogus selection when it gets saved in via selection restoration.
Modified paths:
  • /trunk/phase3/tests/qunit/suites/resources/jquery/jquery.textSelection.test.js (modified) (history)

Diff [purge]

Index: trunk/phase3/tests/qunit/suites/resources/jquery/jquery.textSelection.test.js
@@ -222,3 +222,54 @@
223223 },
224224 replace: ulist
225225 });
 226+
 227+
 228+var caretTest = function(options) {
 229+ test(options.description, function() {
 230+ expect(2);
 231+
 232+ var $fixture = $( '<div id="qunit-fixture"></div>' );
 233+ var $textarea = $( '<textarea>' ).text(options.text);
 234+
 235+ $fixture.append($textarea);
 236+ $( 'body' ).append($fixture);
 237+
 238+ if (options.mode == 'set') {
 239+ $textarea.textSelection('setSelection', {
 240+ start: options.start,
 241+ end: options.end
 242+ });
 243+ }
 244+
 245+ var pos = $textarea.textSelection('getCaretPosition', {startAndEnd: true});
 246+ equal(pos[0], options.start, 'Caret start should be where we set it.');
 247+ equal(pos[1], options.end, 'Caret end should be where we set it.');
 248+ });
 249+}
 250+
 251+var caretSample = "Some big text that we like to work with. Nothing fancy... you know what I mean?";
 252+
 253+caretTest({
 254+ description: 'getCaretPosition with original/empty selection - bug 31847 with IE 6/7/8',
 255+ text: caretSample,
 256+ start: 0,
 257+ end: 0,
 258+ mode: 'get'
 259+});
 260+
 261+caretTest({
 262+ description: 'set/getCaretPosition with forced empty selection',
 263+ text: caretSample,
 264+ start: 7,
 265+ end: 7,
 266+ mode: 'set'
 267+});
 268+
 269+caretTest({
 270+ description: 'set/getCaretPosition with small selection',
 271+ text: caretSample,
 272+ start: 6,
 273+ end: 11,
 274+ mode: 'set'
 275+});
 276+

Follow-up revisions

RevisionCommit summaryAuthorDate
r100398* (bug 31847) Fix positioning of WikiEditor 'header' insertions when selectio...brion00:15, 21 October 2011
r100656Followup r100391: fix caret position test case on Opera, Firefox 3.5/3.6/4.0/5.0...brion22:28, 24 October 2011
r101202REL1_18 MFT r98669, r99031, r99321, r99994reedy21:14, 28 October 2011
r110717[tests] use core qunit-fixture properly...krinkle12:27, 5 February 2012

Comments

#Comment by Krinkle (talk | contribs)   21:19, 24 October 2011
#Comment by Brion VIBBER (talk | contribs)   22:15, 24 October 2011

Bah! Looks like the initial state starts at the end of the textarea on some browsers....

Firefox switched from end to beginning in Firefox 6. Would be nice if we were testing current versions in TestSwarm too. :)

Opera seems to be defaulting to end all the way through current 11.52.

What I really *want* to test is the state after somebody clicks in the field, but I don't quite know how to automate it. :P Probably ok to get a result here that's either at start or at end, as long as it's not a random spot in the middle.

#Comment by Brion VIBBER (talk | contribs)   22:28, 24 October 2011

r100656 should clear that up.

#Comment by Catrope (talk | contribs)   11:49, 28 October 2011

Untagging 1.18wmf1, test case doesn't exist there.

Status & tagging log