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
This was caused by my recent checkin, I'm working on a fix.
Created attachment 4955 [details]
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.
Created attachment 4956 [details]
Comment on attachment 4956 [details]
OK, looks fine. r=me