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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Sep 15 12:06:09 PDT 2011


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





--- Comment #15 from Ryosuke Niwa <rniwa at webkit.org>  2011-09-15 12:06:08 PST ---
(From update of attachment 104955)
View in context: https://bugs.webkit.org/attachment.cgi?id=104955&action=review

>>>>>>>>> Source/WebCore/editing/VisibleSelection.cpp:300
>>>>>>>>> +            if (isEndOfDocument(originalEnd) || (isEndOfLine(originalEnd) && !isStartOfLine(originalEnd) && !isEndOfParagraph(originalEnd)) || (isEndOfWord(originalEnd) && start != originalEnd && m_extent != originalEnd))
>>>>>>>> 
>>>>>>>> I'd split it into two lines since this is really long line.  ap & mitz should probably look at this change.
>>>>>>> 
>>>>>>> No, if c is at the end of a word, endOfWord(c, RightWordIfOnBoundary) returns the end of the following word.
>>>>>> 
>>>>>> 
>>>>> 
>>>>> Given that I'm checking isEndOfWord(originalEnd) && start != originalEnd, without doing the additional m_extent != originalEnd check, word-granularity mouse selections don't work correctly. What happens is given:
>>>>> 
>>>>> foo bar baz
>>>>> 
>>>>> If you double click in 'bar' and drag the mouse to the right to the position after the r in 'bar, it should grow the selection to include the space after 'bar' (in general the next word); it doesn't grow the selection if I omit the check in question.
>>>>> 
>>>>> I do admit it's not very clear what this check is doing; I'll try to find a more clear way to do this check. I initially saw that the first check (if originalEnd is at the end of a word) would fix the problem and added the other two checks to keep other behavior the same.
>>>> 
>>>> Shouldn't we be comparing it with m_end then?
>>> 
>>> originalEnd is declared:
>>> 
>>> VisiblePosition originalEnd(m_end, m_affinity); and is not modified until my check, so there shouldn't be a difference.
>> 
>> But you see
>>     if (m_baseIsFirst) {
>>         m_start = m_base;
>>         m_end = m_extent;
>>     } else {
>>         m_start = m_extent;
>>         m_end = m_base;
>>     }
>> above, right?
> 
> Wouldn't we need to depend on whether or not the base is first? Because the correct behavior from what I understand is that when dragging by word-granularity to the end of a word, the next word gets selected; on the other hand, when dragging by word-granularity to the start of a word, the previous word doesn't get selected. Let me know if I misunderstood your point.
> 
> But I don't see a difference between comparing m_extent to m_end and comparing m_extent to originalEnd in this context.

It seems like your assumption breaks down on Mac since selection is directionless on Mac.

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



More information about the webkit-unassigned mailing list