Bug 13795 – Can't create range from "double-clicked" selection

• Component: New Bugs
• Status: RESOLVED WONTFIX

[fabrice]

Please help because it starts to turns me mad...
When selecting text by double clicking in a word,
var selection = getSelection()
result in the same value for baseOffset and extentOffset, that is, the exact place between two chars where the dblclick occured.
However, the "true" selection may exists actually "somewhere" because :
selection.type returns "Range",
selection.isCollapsed accordingly returns "False",
selection.toString() correctly returns the "visually" selected string (which is insane),
and in a "contentEditable" context, I can perfom operations on it...

The only way I found to retrive the selection is :
var selstring = selection.toString()
Collapse selection to its baseOffset and extentOffset points (which are the same actually).
Then extent selection backward until it matches the start of selstring.
Then extent forward until its length matches the length of selstring.

Regards

Fabrice

[fabrice]

Pease read :
var selstring = new String(selection.toString())
Insead of :
var selstring = selection.toString()

Sorry...

Fabrice

[Justin Garcia]

The anchorNode, anchorOffset, focusNode and focusOffset Selection object properties are what you're after (they behave as they do in FireFox).  Use base and extent if you're interested in knowing more about how the user created the selection (they reflect the selection base and extent before expansion for double or triple clicks).

[fabrice]

Thanks for your reply.
This should be a rather good news for me, but it's not.
My actual target is the shipping Safari in which anchorNode and friends behaves like baseNode and friends (I really thought that there was no difference using either anchor/focus or base/extent).
So, relying on the baseNode family for all my tests, I haven't noticed that WebKit behaves differently.
Sorry for that...
Could you please confirm that the bug exists in the shipping version of Safari ?

Thanks in advance

Regards

Fabrice

[Alexey Proskuryakov]

Yes, there were major problems with those; see bug 4904.

[David Kilzer (:ddkilzer)]

It would be a good idea to make sure your code works with nightlyy WebKit releases:  http://nightly.webkit.org/

[fabrice]

Thanks for the clarification.
What I'm working on is intended to be used by one person on one computer.
However, the debugging phase will involve about ten people. I would have preferred not to require them to use WebKit.
It seems that I have to change my mind again.

(In reply to comment #5)
> It would be a good idea to make sure your code works with nightlyy WebKit
> releases:  http://nightly.webkit.org/
> 
Do you mean "Make sure your code will work with future Safari releases" ?
Yes indeed! :)

Thank you all for your time.

Fabrice

(While I'm here... is somebody knowing a good thread titled like : "misplaced caret in full-justified text"? :)