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