Bug 74346

Summary:

Text selection in text area in auto scroll mode goes wrong.

Product:

WebKit

Reporter:

Misha <mtutunik>

Component:

HTML Editing

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

adele, ap, darin, enrica, eric, jamesr, jchaffraix, max.hong.shen, mifenton, mitz, ojan, rniwa, simon.fraser, sukolsak, tkent, webkit.review.bot, yael

Priority:

Version:

528+ (Nightly build)

Hardware:

Mac (Intel)

OS:

OS X 10.7

Bug Depends on:

94076

Bug Blocks:

Attachments:

Description	Flags
Patch	none
Patch	none
Patch	none

Misha

Reported 2011-12-12 14:52:48 PST

In order to reproduce have a text area filled with a text long enough to be able to scroll the text area up and down. - Scroll the text area down to the end. - Slowly start dragging your mouse starting from the some place in the line closets to the upper edge of the text area. - Once the contents of the text area get scrolled a little notice that the selection jumped down to the end. The selection is not following the current scroll position of the text. If mouse is moved slightly down auto scrolling stops and selection is getting updated to the correct position. If mouse position is not changed then when left button is released the end of the selection can be either at the end of the text or closer to the correct position (where mouse down happened) depending on how much scrolling was done. When auto scrolling is on updateSelectionForMouseDrag() is invoked. Inside we call: VisiblePosition targetPosition = selectionExtentRespectingEditingBoundary(m_frame->selection()->selection(), hitTestResult.localPoint(), target); From what I could see when we start dragging mouse up the offset of the targetPosition is pointing to the end of the text. Reproducible on Mac with Chrome version 15.0.874.121 It might me the same issue as https://bugs.webkit.org/show_bug.cgi?id=31581

Attachments
Patch (9.15 KB, patch) 2012-08-10 05:29 PDT, Sukolsak Sakshuwong	no flags	Details Formatted Diff Diff
Patch (8.85 KB, patch) 2012-08-14 21:08 PDT, Sukolsak Sakshuwong	no flags	Details Formatted Diff Diff
Patch (8.76 KB, patch) 2012-08-14 21:29 PDT, Sukolsak Sakshuwong	no flags	Details Formatted Diff Diff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.

Sukolsak Sakshuwong

Comment 1 2012-08-10 05:29:03 PDT

Created attachment 157713 [details] Patch

Ojan Vafai

Comment 2 2012-08-14 19:01:39 PDT

Comment on attachment 157713 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=157713&action=review R- for the 100ms timeout. The C++ side looks good to me. > LayoutTests/fast/events/autoscroll-in-textarea.html:57 > + var x = textarea.offsetLeft + 20; > + var y = textarea.offsetTop + 8; Can you make these less magic? For x, you can do textarea.offsetLeft + textarea.offsetWidth / 2. For y, would adding 1 be enough? > LayoutTests/fast/events/autoscroll-in-textarea.html:63 > + setTimeout(autoscrollTestPart2, 100); Do you need this 100ms? 0 should be sufficient I would think. No need to make the test take ~100ms longer.

Sukolsak Sakshuwong

Comment 3 2012-08-14 21:08:58 PDT

Created attachment 158495 [details] Patch

Sukolsak Sakshuwong

Comment 4 2012-08-14 21:10:25 PDT

(In reply to comment #2) > (From update of attachment 157713 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=157713&action=review > > R- for the 100ms timeout. The C++ side looks good to me. > > > LayoutTests/fast/events/autoscroll-in-textarea.html:57 > > + var x = textarea.offsetLeft + 20; > > + var y = textarea.offsetTop + 8; > > Can you make these less magic? For x, you can do textarea.offsetLeft + textarea.offsetWidth / 2. > > For y, would adding 1 be enough? > > > LayoutTests/fast/events/autoscroll-in-textarea.html:63 > > + setTimeout(autoscrollTestPart2, 100); > > Do you need this 100ms? 0 should be sufficient I would think. No need to make the test take ~100ms longer. Fixed. Thank you for the comments.

Ojan Vafai

Comment 5 2012-08-14 21:18:21 PDT

Comment on attachment 158495 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=158495&action=review Looks great. Please address my last comments on the test and then feel free to commit. Just to be sure, you verified that the test still fails without your fix and without the setTimeout, right? :) > LayoutTests/fast/events/autoscroll-in-textarea.html:1 > +<!doctype html> Nit: typically we uppercase doctype: <!DOCTYPE html> > LayoutTests/fast/events/autoscroll-in-textarea.html:42 > + testRunner.waitUntilDone(); Now that you don't have the setTimeout, you don't need this line. > LayoutTests/fast/events/autoscroll-in-textarea.html:69 > +if (window.testRunner) > + testRunner.notifyDone(); and without the waitUntilDone call above, you don't need to notifyDone either.

Sukolsak Sakshuwong

Comment 6 2012-08-14 21:29:59 PDT

Created attachment 158497 [details] Patch

Sukolsak Sakshuwong

Comment 7 2012-08-14 21:33:11 PDT

(In reply to comment #5) > (From update of attachment 158495 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=158495&action=review > > Looks great. Please address my last comments on the test and then feel free to commit. > > Just to be sure, you verified that the test still fails without your fix and without the setTimeout, right? :) Yes, I've verified that case. > > LayoutTests/fast/events/autoscroll-in-textarea.html:1 > > +<!doctype html> > > Nit: typically we uppercase doctype: > <!DOCTYPE html> > > > LayoutTests/fast/events/autoscroll-in-textarea.html:42 > > + testRunner.waitUntilDone(); > > Now that you don't have the setTimeout, you don't need this line. > > > LayoutTests/fast/events/autoscroll-in-textarea.html:69 > > +if (window.testRunner) > > + testRunner.notifyDone(); > > and without the waitUntilDone call above, you don't need to notifyDone either. Done. Thank you!

WebKit Review Bot

Comment 8 2012-08-14 22:21:02 PDT

Comment on attachment 158497 [details] Patch Clearing flags on attachment: 158497 Committed r125648: <http://trac.webkit.org/changeset/125648>

WebKit Review Bot

Comment 9 2012-08-14 22:21:08 PDT

All reviewed patches have been landed. Closing bug.

Note You need to log in before you can comment on or make changes to this bug.