Dragging entire text a few pixels replaces it with a '-' (IE) #1240
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Browser: IE9/10
Version: 3.02 +
Link: http://codemirror.net/demo/complete.html
To reproduce:
Result:
Entire text is replaced by a single '-'.
Ow, that's ugly. After an enjoyable two hours spent studying IE's bizarre focus-flipping behavior after a (preventDefault-ed)
dropevent, I found a workaround that seems solid. Attached patch should solve the problem. Please test.Tested on localhost and on http://codemirror.net/demo/complete.html and the problem still exists. :(
Made sure lines from
github.com/marijnh/CodeMirror@475b626cdbare in the script.Are you sure it's not your cache? I just booted up my virtual machine again, but on IE9 I really can not reproduce the problem anymore (using the exact steps you gave). Before above patch, I could reproduce it reliably.
Very sure. Cleared cache, restarted browser and still http://www.youtube.com/watch?v=tLTiQ1_qMao&hd=1
Very odd. If you could try to debug it on your side, that'd be helpful. Basically, the problem that I solved was that IE, after a drag event, cleared the selection inside the hidden textarea. CodeMirror uses the fact that something is selected as a way to detect that no input was typed (in order to not have to constantly fetch the value from the textarea, which is expensive when there's a bunch of text in it). The dash is a placeholder put in when the selection is big, for optimization reasons.
The test I added solved the problem for me because the drag event would reset the textarea's selection to the start of the textarea. It is almost 100% certain that the problem is occuring in
readInput-- since the dash from the textarea ends up replacing the document. The question is, why doesn't my check preventreadInput, on your machine, from going ahead and interpreting the content of the textarea as new input. For a start, I'd be interested what theselectionStartandselectionEndare right after that test (a code path that should only be executed once when performing your bug reproduction steps).I set a breakpoint just after the if statement ( line 1354 ) and selectionEnd = 1, selectionStart = 1. I had another breakpoint inside the if statement ( line 1351 ), but it never entered.
I see. That's useful. Something makes your IE deselect differently than mine. Unfortunately, that's harder to detect, since it puts the textarea in a state similar to what it would be in during regular typing. I'll see if I can find a workaround.
FYI: I've been debugging on IE 10.0.9200.16441 ( installable on win7 ) and get the same result in IE10 & IE9 browser mode.
mentioned in issue #1445
Sorry for leaving this sitting for so long. It kind of fell through the cracks of my inbox.
I've finally installed IE10, and I think the attached patch should help. Please test.
I could not reproduce the bug anymore! Thank you for the fix!