Dragging entire text a few pixels replaces it with a '-' (IE) #1240

Closed
opened 2013-02-13 15:24:13 +01:00 by marijnh · 11 comments
marijnh commented 2013-02-13 15:24:13 +01:00 (Migrated from gitlab.com)

Browser: IE9/10
Version: 3.02 +
Link: http://codemirror.net/demo/complete.html

To reproduce:

  1. Select entire text
  2. Drag last 'd' onto the 'n' just before ( or basically move the selection a few pixels to the left )

Result:
Entire text is replaced by a single '-'.

Browser: IE9/10 Version: 3.02 + Link: http://codemirror.net/demo/complete.html To reproduce: 1) Select entire text 2) Drag last 'd' onto the 'n' just before ( or basically move the selection a few pixels to the left ) Result: Entire text is replaced by a single '-'.
marijnh (Migrated from gitlab.com) closed this issue 2013-02-14 10:57:43 +01:00
marijnh commented 2013-02-14 10:59:11 +01:00 (Migrated from gitlab.com)

Ow, that's ugly. After an enjoyable two hours spent studying IE's bizarre focus-flipping behavior after a (preventDefault-ed) drop event, I found a workaround that seems solid. Attached patch should solve the problem. Please test.

Ow, that's ugly. After an enjoyable two hours spent studying IE's bizarre focus-flipping behavior after a (preventDefault-ed) `drop` event, I found a workaround that seems solid. Attached patch should solve the problem. Please test.
marijnh commented 2013-02-18 15:45:58 +01:00 (Migrated from gitlab.com)

Tested on localhost and on http://codemirror.net/demo/complete.html and the problem still exists. :(
Made sure lines from github.com/marijnh/CodeMirror@475b626cdb are in the script.

Tested on localhost and on http://codemirror.net/demo/complete.html and **the problem still exists**. :( Made sure lines from https://github.com/marijnh/CodeMirror/commit/475b626cdb42a426278de3c87fa50ccd751cfb6f are in the script.
marijnh commented 2013-02-19 10:30:28 +01:00 (Migrated from gitlab.com)

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.

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.
marijnh commented 2013-02-19 10:44:58 +01:00 (Migrated from gitlab.com)

Very sure. Cleared cache, restarted browser and still http://www.youtube.com/watch?v=tLTiQ1_qMao&hd=1

Very sure. Cleared cache, restarted browser and still http://www.youtube.com/watch?v=tLTiQ1_qMao&hd=1
marijnh commented 2013-02-19 10:52:24 +01:00 (Migrated from gitlab.com)

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 prevent readInput, on your machine, from going ahead and interpreting the content of the textarea as new input. For a start, I'd be interested what the selectionStart and selectionEnd are right after that test (a code path that should only be executed once when performing your bug reproduction steps).

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 prevent `readInput`, on your machine, from going ahead and interpreting the content of the textarea as new input. For a start, I'd be interested what the `selectionStart` and `selectionEnd` are right after that test (a code path that should only be executed once when performing your bug reproduction steps).
marijnh commented 2013-02-19 11:02:35 +01:00 (Migrated from gitlab.com)

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 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.
marijnh commented 2013-02-19 11:20:10 +01:00 (Migrated from gitlab.com)

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.

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.
marijnh (Migrated from gitlab.com) reopened this issue 2013-02-19 11:20:12 +01:00
marijnh commented 2013-02-19 11:22:23 +01:00 (Migrated from gitlab.com)

FYI: I've been debugging on IE 10.0.9200.16441 ( installable on win7 ) and get the same result in IE10 & IE9 browser mode.

FYI: I've been debugging on IE 10.0.9200.16441 ( installable on win7 ) and get the same result in IE10 & IE9 browser mode.
marijnh commented 2013-04-10 17:00:16 +02:00 (Migrated from gitlab.com)

mentioned in issue #1445

mentioned in issue #1445
marijnh commented 2013-04-15 11:24:24 +02:00 (Migrated from gitlab.com)

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.

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.
marijnh commented 2013-04-15 12:58:33 +02:00 (Migrated from gitlab.com)

I could not reproduce the bug anymore! Thank you for the fix!

I could not reproduce the bug anymore! Thank you for the fix!
marijnh (Migrated from gitlab.com) closed this issue 2013-04-15 12:58:33 +02:00
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
codemirror/codemirror5#1240
No description provided.