timdown
Selecting a node does not work well in IE
From [email protected] on January 01, 2011 10:33:19
What steps will reproduce the problem? 1.Use the following HTML:
function testClone(node){ var range = rangy.createRange(); range.selectNode(node); document.body.appendChild(range.cloneContents());
rangy.getSelection().setSingleRange(range);
var range2 = rangy.getSelection().getRangeAt(0); document.body.appendChild(range2.cloneContents());
if (document.selection){ alert(document.selection.createRange().htmlText); } }
text
1. click on the blue text What is the expected output? What do you see instead? Expected result is that the paragraph is copied exactly as it is 2 times. (It works like this in Firefox) But actual result is that the second copy is only text without the paragraph. What version of the product are you using? On what operating system? Rangy 1.0 Please provide any additional information below. I have tried that there is difference between using selectNode and selectNodeContents in what the htmlText property of IE native range returns. But there is not difference in the resulting range2.So the setting of the native range in setSingleRange seems to be correct, but the backward conversion to rangy range is not.
Original issue: http://code.google.com/p/rangy/issues/detail?id=25
From [email protected] on January 01, 2011 05:17:45
The problem is what the browser does when you select a Range, which Rangy cannot control. Internet Explorer is the biggest problem since its TextRange fundamentally has little to do with DOM nodes, but WebKit (and hence Safari and Chrome) has serious problems too. The Selection docs ( http://code.google.com/p/rangy/wiki/RangySelection ) talk about this quite a lot, particularly in the introduction and the sections on addRange() and getRangeAt(). There's not a lot that can be done, unfortunately.
Status: CantFix
From [email protected] on January 01, 2011 07:36:42
I have tried to add the following to the end of WrappedRange.prototype.refresh function and it fixes it.
if (!textRangeIsCollapsed(this.textRange)){ var clone = this.cloneRange(); var startNode = rangy.dom.getClosestAncestorIn(start.node, rangeContainerElement, true); var startIndex = rangy.dom.getNodeIndex(startNode);
var endNode = rangy.dom.getClosestAncestorIn(end.node, rangeContainerElement, true);
var endIndex = rangy.dom.getNodeIndex(endNode) + 1;
clone.setStart(rangeContainerElement, startIndex);
clone.setEnd(rangeContainerElement, endIndex);
var htmlText = this.textRange.htmlText;
var textRangeResult = WrappedRange.rangeToTextRange(clone);
if (htmlText == textRangeResult.htmlText){
this.setStart(rangeContainerElement, startIndex);
this.setEnd(rangeContainerElement, endIndex);
}
} It fixes both cases (using range.selectNodeContents and range.selectNode) the resulting RangyRange is the same as before setting it.
Of course it will need testing in different situations and probably some optimalizations, but it shows that something can be done...
From [email protected] on January 02, 2011 17:07:07
Using htmlText to test the validity of (and possibly alter) the Range created from a TextRange is an interesting idea. I think I have previously considered it but rejected it on performance grounds. I'm also not sure how effective it would be in general: I haven't done any testing on the htmlText TextRange property. I'm very suspicious of IE's HTML string representations of anything.
Your example extra code is definitely flawed (it caused some of my tests to fail), but I haven't yet had time to work out exactly how, so I'll have to look into this more deeply.
Status: Accepted
From [email protected] on June 14, 2012 02:56:45
I haven't prioritised this because:
- selection boundaries are inconsistent between browsers anyway and most browsers do not allow selection boundaries to be located at every single possible position in the document. Both WebKit and IE have internal ideas about what are possible positions for selection boundaries and the caret, and will always normalize selection boundaries to the nearest visible position. I prefer Rangy to reflect this rather than pretend otherwise.
- there's no need to involve selections for this example in any case
- the chances of it being a good general solution to use htmlText for anything seems small to me. It will have a (possibly high) performance cost and I simply don't trust it based on experience of using TextRanges.
However, I will look into this before releasing version 1.3.
I haven't done anything with this for 1.3. I will tag it for 1.4 but it's low priority.
Selecting tree view is not firing the event in ie11 .It is working in Chrome.I am using angular typescript
nodeSelected(node: any) nodeSelected(node: any) { this.selectedNode = node;
}
<app-tree [(treeData)]="data"
(onNodeChanged)="nodeUpdated($event)"
(onNodeSelected)="nodeSelected($event)"></app-tree>
