Opened 5 years ago

Closed 5 years ago

#17639 closed defect (fixed)

Editor IndexSizeError in IE10+

Reported by: haysmark Owned by: Colin Snover
Priority: high Milestone: 1.7.6
Component: Editor Version: 1.8.4
Keywords: Cc:
Blocked By: Blocking:

Description

Related: #14331

See:

http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/editor/test_Editor.html

  1. In the second editor, highlight the first word.
  2. In the toolbar, click the Bold button. The text should turn bold. Click Bold again to return the text to normal.
  3. Highlight the last word.
  4. In the toolbar, click the Bold button. You get an IndexSizeError? in the w3c block of Editor's _moveToBookmark:

if(sNode && eNode){
	// Okay, we believe we found the position, so add it into the selection
	// There are cases where it may not be found, particularly in undo/redo, when
	// formatting as been done and so on, so don't restore selection then.
	r.setStart(sNode, mark.startOffset);
	r.setEnd(eNode, mark.endOffset); // ERROR HERE
	sel.addRange(r);
}

You may also notice the text cursor jumping erratically as you use the toolbar; I assume the Editor is losing track of the cursor position.

In terms of workarounds, using the keyboard shortcuts seems to work fine. Also, if you re-select the bold text before pressing the Bold button for a second time to revert the text to normal, no bad things happen. I assume this resets and updates the current selection in light of the changes to the DOM.

Forcing the has(ie) branch doesn't actually help because it falls through into a pseudo-w3c branch with materially similar code.

It seems to work fine in IE9 mode.

Attachments (2)

test.html (1.5 KB) - added by Sebastien Brunot 5 years ago.
Demonstrate issue with the fix with a simple digit example
ss.html (431 bytes) - added by bill 5 years ago.
a demo that is in standards-mode and does not have invalid html

Download all attachments as: .zip

Change History (13)

comment:1 Changed 5 years ago by Colin Snover

Milestone: tbd1.9.4
Owner: set to Colin Snover
Priority: undecidedhigh
Status: newassigned

This issue is due to the -ms-user-select CSS property not working the same as the unselectable DOM attribute, so when the mouse button presses in the toolbar, the content of the frame is inappropriately unselected.

In my testing, this defect is not reliably reproduced and occurs as a race condition depending upon how quickly the user is interacting with the editor and how slowly their computer runs, so I can fix it but I can’t add an automated test that will reliably capture the failure.

comment:2 Changed 5 years ago by Colin Snover <github.com@…>

Resolution: fixed
Status: assignedclosed

In 7ae2a43b608eae921b862b7feb6f2910bb45b03a/dojo:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:3 Changed 5 years ago by Colin Snover <github.com@…>

In e61aff23544049921d406ec5754da1e2e3e14309/dojo:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:4 Changed 5 years ago by Colin Snover <github.com@…>

In 0a7036f4d8a66b280387d24db91eeec925e2ef9c/dojo:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:5 Changed 5 years ago by Colin Snover <github.com@…>

In 3066a3cb447d6df826c4abb24a5f58358249a0bc/dojo:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:6 Changed 5 years ago by Colin Snover

Milestone: 1.9.41.7.6

comment:7 Changed 5 years ago by Sebastien Brunot

This fix breaks some dojo mobile components in IE10 and IE11, because setting the unselectable attribute to "no" on an input field has the side effect that it is not focused when it is clicked.

Here are two examples of dojo mobile components that are broken by this fix:

A) ScrollablePane?:

If a scrollable pane contains input elements, they are not focused when clicked.

B) Heading:

1) launch the manuel test page dojox/mobile/tests/test_Opener-SearchList?-async.html 2) Click the input field: an opener popup 3) Click the Search field in the opener: it doesn't get the focus.

Last edited 5 years ago by Sebastien Brunot (previous) (diff)

Changed 5 years ago by Sebastien Brunot

Attachment: test.html added

Demonstrate issue with the fix with a simple digit example

comment:8 Changed 5 years ago by Sebastien Brunot

I've attached a simple digit example (test.html) that demonstrate the side effect of the fix: on IE10 (and IE9, not tested with IE11), the input field on the left pane is not focused when clicked.

comment:9 Changed 5 years ago by Sebastien Brunot

Resolution: fixed
Status: closedreopened

comment:10 Changed 5 years ago by Patrick Ruzand

Hi, any thoughts ?

thx

Changed 5 years ago by bill

Attachment: ss.html added

a demo that is in standards-mode and does not have invalid html

comment:11 Changed 5 years ago by dylan

Resolution: fixed
Status: reopenedclosed

Dojo Mobile has worked around this issue, so I'm going to mark this as closed. If there's a desired change in the standard behavior, let's open a separate ticket to fix that.

Note: See TracTickets for help on using tickets.