[Webkit-unassigned] [Bug 36359] Double clicking page's last editable inline element doesn't select a word.

[bugzilla-daemon at webkit.org]

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





--- Comment #19 from MORITA Hajime <morrita at google.com>  2010-05-24 05:20:41 PST ---
Hi Ojan, thank you for feedback!

> LayoutTests/editing/selection/doubleclick-inline-first-contenteditable.html:14
>  +      while (n) {
> You only need this code if you have positioned elements. For this test, you can just directly use target.offsetLeft, target.clientLeft, etc. No while loop needed.
Fixed.

> LayoutTests/editing/selection/doubleclick-inline-first-contenteditable.html:30
>  +      eventSender.leapForward(50);
> You shouldn't need this leapFoward for a doubleclick. Did you find it didn't work without it?
Fixed.
> 
> Can you combine the two tests into one using HTML like the following: <div><span id="target" contentEditable="true">first</span> double click <span id="target" contentEditable="true">last</span></div>
>
Fixed to combine 2 into 1.

> WebCore/editing/visible_units.cpp:164
>  +              // editing boundary. So we lookup editable node from the candidates.
> I think this works correctly, but is a bit messy to fix it up after the fact. The best fix I can think of would be to modify TextIterator to have a TextIteratorBehavior that tells it to avoid crossing editing boundaries. I'm sure this won't be the only case where we'll want TextIterators to respect editing boundaries. That's a complicated change though. I'm OK with just adding FIXME here for now, but I'd like feedback from other reviewers. r- for now for the test changes and adding this fixme.
It seems good idea to make TextIterator aware editing-boundary.
So I did it for SimplifiedBackwardsTextIterator which we are using in this case.

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