Bug 25744 – typing does not go where window.getSelection() claims it will after an anchor

• Status: NEW
• Component: HTML Editing

[Eric Seidel (no email)]

typing does not go where window.getSelection() claims it will after an anchor

See attached test case.

[Eric Seidel (no email)]

Created attachment 30260 [details]
test case

[Eric Seidel (no email)]

Technically, I guess this counts as a regression.  Since before, event though you could never get your cursor outside of a link, we wouldn't lie about where it was. :)

That said, if we ever fix selection to have full fidelity it will "lie" a lot more than this, as you'll be able to set it to non-typable positions which will be normalized before typing.

[Eric Seidel (no email)]

So I can't fix where the typing goes w/o having to fix full selection fidelity.  If the desired behavior of this bug is to change how things are reported, that's possible.  It is also possible to detect and predict where the text would go from JS.  It may be a non-trivial amount of JS.

[Hajime Morrita]

Current behaviour looks expected one.
I tried to fix this then found a conflicting testcase.
See LayoutTest/editing/inserting/insert-before-link-1.html.

Comments on CompositeEditCommand::positionAvoidingSpecialElementBoundary() says 
this behaviour is to align NSTextView. 
To know how NSTextView gives hyperlinks to text programatically, we
can use the test program provided by Apple:
http://developer.apple.com/Mac/library/samplecode/TextLinks/index.html

On the other hand, NSTextView behaviour also looks inconsistent.
While it doesn't give the link to inserted texts, it gives highlight
color to them.  So after insertion, there is a blue-highlighted,
non-linking text, which might be confusing and weird in HTML sense.

So reasonable alternatives are:
1. To keep current behaviour: inserted text after anchor is not give linked.
2. To give link for the inserted text. (I'll submit a patch shortly.)

I prefer 1 for the reason eric mentioned. But we need a consensus.

[Hajime Morrita]

Created attachment 51015 [details]
chagne to allow inserting text into end of the anchor

[Julie Parent]

How does this effect the user placing a cursor manually at the end of the link and typing?  Note that the behavior to NOT type inside the link was done deliberately in http://trac.webkit.org/changeset/38683 and is desired.

This bug is about how getSelection doesn't match what is used internally by WebKit, and is asking getSelection to report the position outside the link, rather than inside, since typing will go outside.  This will allow web applications to be able to check the selection using getSelection and know where typing will go at that point.

[Hajime Morrita]

> How does this effect the user placing a cursor manually at the end of the link
> and typing?  Note that the behavior to NOT type inside the link was done
> deliberately in http://trac.webkit.org/changeset/38683 and is desired.
Uh, I missed this one. Current patch is wrong. 
Thank you for pointing it out.

> 
> This bug is about how getSelection doesn't match what is used internally by
> WebKit, and is asking getSelection to report the position outside the link,
> rather than inside, since typing will go outside.  This will allow web
> applications to be able to check the selection using getSelection and know
> where typing will go at that point.
Agreed. 
Before editing, WebKit forces to locate the selection to meet a certain criteria.
What wrong would be the timing when it forces the location. 
So more desirable approach would force the selection location after 
each selection movement.