Opened 8 years ago

Closed 8 years ago

#1280 closed defect (fixed)

restoreSelection doesn't always work in internet explorer

Reported by: douglas Owned by:
Priority: normal Milestone: 0.96
Component: Browsers_InternetExplorer Version: trunk
Severity: normal Keywords: ie workaround
Cc:

Description

When restoring a selection in internet explorer, if the textrange object points to the end of a text node that immediately precedes a block element, the selection isn't properly restored. This is because of a bug in IE when calling the select() method on a TextRange?. The cursor is moved forward one node into the beginning of the following block node.

Attachments (1)

test.html (2.0 KB) - added by douglas 8 years ago.
Test case that demonstrates the problem

Download all attachments as: .zip

Change History (7)

Changed 8 years ago by douglas

Test case that demonstrates the problem

comment:1 Changed 8 years ago by douglas

  • Resolution set to fixed
  • Status changed from new to closed

r1040 Offers up three different fixes ('InsertSpan?', 'JustificationHack?', and 'VisiblePrompt?', the default) each with different tradeoffs for the user. The fix is user configurable by setting 'selectWorkaround' in the config to one of the three options.

comment:2 Changed 8 years ago by ray

  • Resolution fixed deleted
  • Status changed from closed to reopened

Doug, there is a function Xinha.uniq() in the core which provides a globally unique id based on an increasing number, which I think you should use in your code

comment:3 Changed 8 years ago by douglas

  • Resolution set to fixed
  • Status changed from reopened to closed

Ray, I already looked at Xinha.uniq(), but it's designed to give a unique id over the lifetime of the Xinha instance. Because of the nature of the IE workaround, it's unfortunately possible to litter these spans back into the document (and a large number of them, which is why this fix is not the default). In this instance, in a worst case situation, I would be going back to uniq() to pull id after id to try and get one that is unique. By doing it with a random suffix and an increasing keyspace, I keep from having to search linearly through the list of ids. My solution doesn't work in a general case, which is why I can't port it back to uniq(), but in this specific situation it has a lower chance of causing problems.

comment:4 Changed 8 years ago by ray

  • Resolution fixed deleted
  • Status changed from closed to reopened

Doug, your patch produces an error

Line: 427
Error: 'undefined' is Null or not an object

comment:5 Changed 8 years ago by nicholasbs

What version of IE are you using, Ray? I'm pretty sure Doug's been testing against IE 6 and 7, so it might be an issue with IE8 if you're using that.

comment:6 Changed 8 years ago by ray

  • Resolution set to fixed
  • Status changed from reopened to closed

rev [1056]: Ok, the bug was not really in your patch, it just revealed it. It was Dialog.hide() that called restoreSelection(), and wrongly so for example with Stylist as already assumed by nicholas in a code comment. restoreSelection() in Dialog.hide() makes only sense with modal dialog, as the selection is only saved with those in Dialog.show(). For safety I nevertheless return in restoreSelection() when no savedSelection is passed

Note: See TracTickets for help on using tickets.