getCharacterRanges seem to give inconsistent result

[geyang]

Dear @timdown ,

I have been able to replicate this problem but wasn't able to setup a plunkr. I will try to come back to create one later.

 OS: Max OSX Yosemite
 Browser: Chrome 40.0.2214.115 (64-bit)

When there is the following html:

<pre class="code-block lang-javascript ng-scope"><span class="hljs-keyword">var</span> </pre>

when the cursor is at the end of the <pre> block, the getCharacterRanges return position 12 instead of 4.

happens in Chrome.

[geyang]

This has been very consistent. I am going to dig into the source to figure out what's going on.

Any tips?

[geyang]

I think the bug is inside the boundary updater or the rangeBetween.rext() function.

basically when

rangeBetween.setStartAndEnd(parent, nodeIndex, this.startContainer, this.startOffset);
startIndex = rangeBetween.text(characterOptions).length;

[geyang]

The bug is in rangeBetween.text(characterOptions). This function returns a strange string from somewhere else on the webpage, couple of layers after the editor area.

uhm any tips?

and thanks for this great library!!

[geyang]

I also get a DOM exception in safari.

[geyang]

Hi @timdown ,

I got the code to work by making the following changes: Instead of setting the beginning of the range by the parent node and the node index, you set the range to the 0th offset of the current container.

Please advice :)

                    if (rangeStartsBeforeNode) {
                        rangeBetween.setStartAndEnd(this.startContainer, this.startOffset, containerNode, 0);
                        startIndex = -rangeBetween.text(characterOptions).length;
                    } else {
                        rangeBetween.setStartAndEnd(containerNode, 0, this.startContainer, this.startOffset);
                        startIndex = rangeBetween.text(characterOptions).length;
                    }

[geyang]

Dear @timdown ,

I just submitted a pull request with the forementioned fix. Please let me know if this makes sense!!

Otherwise, I would also love to know if there is another way to fix this.

Cheers!!

[timdown]

I'm struggling to replicate the problem. Could you give me a bit more detail, please? More of the HTML and how to get the cursor in the problematic position would be ideal.

[geyang]

Hey Tim,

Here is an example html that is not editable: if I replace the <pre> tag's innerHTML with the html in this page ('s <pre> tag), the textRange function will NOT give the correct text for the selection between the beginning of the containerNode and the caret. It will give something instead.

http://lesquare.escherpad.com/@yang.ge/title-block-3nv00s3qcrtn
The problem is very hard to replicate because I am using textAngular with a custom code-block code high-lighting directive, so there are quite a few layers of code in my case.

However the description above is what happens.

[timdown]

Sorry if I'm being stupid but I just can't seem to get an error. On your page, I selected the final closing brace character, opened the console and called

rangy.getSelection().saveCharacterRanges(document.getElementsByTagName("pre")[0])

and got a character range with start 46 and end 47, which is correct. I used the same HTML in a unit test, tried placing the caret at various points and they all came out correct.

I'm sure there could well be a bug but I need to see it before fixing it or confirming your fix.

[geyang]

Hi Tim,

that page is actually using my patched version of rangy!! In my patched version (which you can see here #L288), instead of using the child node index and set the start from the parent[nth]child, I pass the child in directly and set the start offset to the beginning of the child.

This seems to fix the issue.

I understand that we need to replicate the issue first. Let me try to finish what I am working on and I will try my best to replicate the issue.

Thanks for this great library and all the answers on Stackoverflow!

[timdown]

Ahhh. I'll have another try based on your page later today then.

[timdown]

Took me longer than expected to get to this, sorry. I had another go by wiping the rangy variable in the console and pasting in the current unpatched code. I still couldn't replicate the issue. Frustrating.

[geyang]

Hey Tim, I will try to get back to this sometime this weekend. I suspect that it has something to do with my app loading another copy of rangy inside of an iframe. Ge

[geyang]

Hi Tim, I tried to setup a jsfiddle for this, but the fiddle is working flawlessly.

Here is the link: http://jsfiddle.net/episodeyang/jk1s7adn/

I really want to solve this issue, would you mind have a look at my app? Even if it is a problem with something in my app, I think you might come up with a reason for the bug. In the production code below, I have added lots of console.log so the error should be easy to spot.

Here is the description:

http://lesquare.escherpad.com/@yang.ge/How-to-Replicate-the-issue-286-ebl3j2guyct4