EnterKeyHandling blockNodeForEnter=BR failure on IE9

[bill]

GROUP "blockNodeForEnter=BR" has 4 tests to run PASSED test: ../../dijit/tests/editor/robot/EnterKeyHandling.html::blockNodeForEnter=BR::wait for editors to load 426 ms PASSED test: ../../dijit/tests/editor/robot/EnterKeyHandling.html::blockNodeForEnter=BR::type in some text 6543 ms     _AssertFailure: assertEqual() failed: 	expected
		testingCopyAndPastetestingCopyAndPastetestingCopyAndPaste<br/>
	but got
		testingCopyAndPaste<br/>testingCopyAndPastetestingCopyAndPaste

 with hint: 
		get('value')
     ERROR IN: 		 function(){
							var d = new doh.Deferred();

							var br = dijit.byId("br");
							br.set("value", "");
							br.focus();
							
							doh.robot.mouseMoveAt(br.iframe, 500);
							doh.robot.mouseClick({left:true}, 500);
							doh.robot.keyPress(dojo.keys.BACKSPACE, 500, {});
								
							doh.robot.typeKeys("testingCopyAndPaste", 500);
							doh.robot.keyPress("a", 500, metaKey);	// select all
							doh.robot.keyPress("c", 500, metaKey);	// copy
							doh.robot.keyPress("v", 500, metaKey);	// paste
							doh.robot.keyPress("v", 500, metaKey);	// paste
							doh.robot.keyPress("v", 500, metaKey);	// paste
							doh.robot.keyPress(dojo.keys.ENTER, 500, {shift: false});
							doh.robot.sequence(d.getTestCallback(function(){
								// get('value') should call the post-filter which recombines the separate <p> nodes into bigger
								// paragraphs.
								var value = br.get('value');
								value = value.replace(/ /g, "");
								value = value.replace(/\xA0/g, "");
								if(dojo.isWebKit && !dojo.isMac){
									// Work around webkit bug: 
									// http://code.google.com/p/chromium/issues/detail?id=106551
									// Should hopefully be fixed in Chrome 19.
									value = value.replace(/\n/g, "");
									value = value.replace(/\r\f/g, "");
								}
								
								// Safari may end with a trailing/extra br, so we need to remove it.
								if(/<br\/><br\/>$/.test(value)){
									value = value.substring(0, value.length - 5);
								}
								doh.is('testingCopyAndPastetestingCopyAndPastetestingCopyAndPaste<br/>',
										value,
										"get('value')");
							}), 1000);
							return d;
						} FAILED test: ../../dijit/tests/editor/robot/EnterKeyHandling.html::blockNodeForEnter=BR::copy and paste 6151 ms

[bill]

Jared, hopefully you can look at this since you just fixed the chrome test failure.

[Jared Jurkiewicz]

This appears to be a bug in the IE range selection API that rears its ugly head when copy/paste are used. For some reason IE doesn't update its internal range selection on paste. Clicking, moving the key, anything else will. I'm trying to find a workaround that doesn't involve falling back to the old windows selection API

[Jared Jurkiewicz]

Figured out a workaround. As this is only an issue with the onpaste event, it can be managed there. The older (proprietary) range code IE has can be used to get IE to update its internal range/selection state so the WC3 range API continues to work properly. It's a bit odd of a workaround, but it does work. It's a matter of 'moving' the range back one characterm then forward one character, on each paste. This gets IE to update the W3C data structures it has so that then the paste action works.

[Jared Jurkiewicz]

In [28185]:

Fix for IE 9 issue with cut/paste and IE 9 W3C range API. IE bug,. This is a workaround to mitigate it. !strict fixes #14949

[Jared Jurkiewicz]

In [28186]:

Fix for IE 9 issue with cut/paste and IE 9 W3C range API. IE bug,. This is a workaround to mitigate it. \!strict fixes #14949

[bill]

Will this work if pasting into the very beginning of the document, or into an empty document? You presumably can't move one character before the beginning of the selection, although you could shrink the selection by one character. I'm not sure which of those your code is doing.

[Jared Jurkiewicz]

Yes, it will work pasting at the beginning of the document. I tried it. That is, in fact a lot of what the test really does. And that's exactly what the code I put in does, it's messing with the end of the pasted content. The old selection api 'works' with regard to cursor position after a paste. It's the W3C one that initially doesn't until you kick IE wiht the old api to get it to update.

[Douglas Hays]

[28186] changed dojo/_base/sniff to dojo/sniff but I don't see that module in the 1.7 branch.

[Jared Jurkiewicz]

In [28197]:

Use right sniff module for 1.7. \!strict fixes #14949

[bill]

In [30091]:

Editor EnterKeyHandling IE10 fixes:

• There's some code that was needed for IE9 (refs #14949); turns out it's also needed for IE10
• There's also a section of IE code that apparently isn't needed on IE10, so made that specific to IE <= 9.
  • IE10 has auto-correction, so splitting the word "is" into "i" an "s" will cause the "I" to capitalize; avoid that browser-specific behavior by capitalizing it to begin with.
• Miscellaneous fixes to test file.

Fixes #16127 on trunk !strict.

[bill]

In [30092]:

Editor EnterKeyHandling IE10 fixes:

• There's some code that was needed for IE9 (refs #14949); turns out it's also needed for IE10
• There's also a section of IE code that apparently isn't needed on IE10, so made that specific to IE <= 9.
  • IE10 has auto-correction, so splitting the word "is" into "i" an "s" will cause the "I" to capitalize; avoid that browser-specific behavior by capitalizing it to begin with.
• Miscellaneous fixes to test file.

Fixes #16127 on 1.8 branch !strict.

[bill]

In [30248]:

Backport [28185] EnterKeyHandling IE9 fixes to 1.6 branch, fixes #14949 on 1.6 branch !strict. For some reason though I had to setup the onpaste listener on editor.document.body rather than on editor.document, like 1.7 does.

Backport EnterKeyHandling IE10 code and test fixes from [30091] to 1.6 branch. Fixes #16127 on 1.6 branch !strict