[Webkit-unassigned] [Bug 36256] shift+click to extend a wordgranularity selection backwards selects the space after

[bugzilla-daemon at webkit.org]

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





--- Comment #18 from Van Lam <vanlam at google.com>  2011-09-15 16:53:10 PST ---
(In reply to comment #17)
> (In reply to comment #16)
> > I'm not sure how that breaks down my assumption (what is my assumption exactly?). Mac selections while directionless are still implemented using base and extent such that the greater of the two is used to determine the end of the selection.
> > 
> > But understanding that this proposed fix produces the correct behavior while keeping other behavior the same (no test failures in editing/selection/), do you have any suggestions on how it can be further improved?
> 
> This area is very under-tested so the fact your patch doesn't break any tests isn't a good indication that your change is correct. In fact, we should never assume the correctness of code purely based on tests pass.
> 
> Having said that, m_extent can be either at the beginning or at the end of selection depending on the value isBaseFirst and from what you're saying, it seems like you need to compare originalEnd with whichever selection endpoint that appears later in the document order.

The check in question (m_extent != originalEnd) is introduced only to handle the case when the user double clicks on a word and drags (with the cursor position corresponding to the extent of the selection) forward towards the end of the word; the context is determining whether the later(/greater offset) endpoint of the selection should be increased so that the selection includes the next word. This is why I compared m_extent to originalEnd.

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