Bug 5936 - REGRESSION: selection keeps growing after double-click
Summary: REGRESSION: selection keeps growing after double-click
Status: VERIFIED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P1 Normal
Assignee: Justin Garcia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-04 22:27 PST by Alexey Proskuryakov
Modified: 2005-12-05 21:54 PST (History)
0 users

See Also:


Attachments
patch (12.93 KB, patch)
2005-12-05 00:19 PST, Justin Garcia
no flags Details | Formatted Diff | Diff
patch (14.55 KB, patch)
2005-12-05 00:25 PST, Justin Garcia
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Proskuryakov 2005-12-04 22:27:53 PST
Steps to reproduce: 
1. Double-click any word on this page
2. Move the mouse pointer one line up

Results: The selection starts expanding forward character by character, until it reaches the end of 
paragraph.
Comment 1 Justin Garcia 2005-12-04 22:29:59 PST
This was caused by my recent checkin, I'm working on a fix. 
Comment 2 Justin Garcia 2005-12-05 00:19:10 PST
Created attachment 4955 [details]
patch

I rolled out my fix for 5856 and rewrote it.

The bug in 5856 was caused because validate() was making changes to the
selection (expansion) that weren't themselves corrected by validate().	The
part of validation that is important for the bug is adjustForEditableContent(),
which prevents the selection from straddling an editable/non-editable boundary.
 In this patch, adjustForEditableContent() is called after expansion, and I
modified it to take into account the possibility of start/end being distinct
from base/extent.  Base/extent will be distinct from start/end when expansion
is done.  Expansion happens when you a) double or triple click, or b) when you
modify a selection that was created by double or triple clicking.  When you
modify a selection that was created by a double or triple click, the new
selection uses word or paragraph granularity, respectively.

Originally, I thought that SelectionController could be changed to keep just
two positions and a boolean (baseIsStart).  But keeping four positions in
SelectionController is probably the most straightforward way of implementing
the second type of expansion mentioned above, otherwise the Part would have to
keep track of the base of the selection.  In addition, adjustForEditableContent
wouldn't be able to do its job after an expansion if it didn't know where the
user based the selection.

The patch also renames m_baseIsStart to m_baseIsFirst, since base/extent are
sometimes distinct from start/end.
Comment 3 Justin Garcia 2005-12-05 00:25:54 PST
Created attachment 4956 [details]
patch
Comment 4 Darin Adler 2005-12-05 06:34:50 PST
Comment on attachment 4956 [details]
patch

OK, looks fine. r=me
Comment 5 Justin Garcia 2005-12-05 20:30:08 PST
landed