[Webkit-unassigned] [Bug 107850] Make moveCaretTowardsWindowPoint not snap to the beginning/end when moved above/below editable

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=107850


Ojan Vafai <ojan at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |darin at apple.com,
                   |                            |leviw at chromium.org




--- Comment #9 from Ojan Vafai <ojan at chromium.org>  2013-01-30 17:23:24 PST ---
(In reply to comment #8)
> (In reply to comment #6)
> > (From update of attachment 184834 [details] [details])
> > Can we fix this by adding EditingAndroidBehavior and making it do the same as EditingWindowsBehavior in the right places or does that not work for some reason?
> 
> That would be nice... I tried that first: https://bugs.webkit.org/show_bug.cgi?id=107171

Sigh. I agree with Darin obviously (Darin and I came up with the concept EditingBehavior in the first place). Android is a different OS and has different editing behavior. I don't see what the problem is with adding a new editing behavior is. It's not like we get a new OS that often.

> Really though, moveCaret should have that behavior on all platforms that use it. 

This is not clear to me. It seems like it should just respect whatever editing behavior you pick. Why would another platform choose to use this but not want their platform's normal editing behavior?

> rniwa@ mentioned the possibility of having positionForPoint optionally take a flag for shouldMoveCaretTo[...]. Currently EditingBehavior::shouldMoveCaret[...] is used in RenderBlock::positionForPointWithInlineChildren and its setting completely changes the behavior of RenderObject::positionForPoint. It makes sense to me for that to actually be more exposed/obvious to callers of positionForPoint. What do you think?

Adding a new EditingBehavior is the clear correct approach here IMO. We should just do that as per your first patch on bug 107171. Please upload that patch + tests and I will approve it. Sorry you've gotten the runaround on this.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.