[Webkit-unassigned] [Bug 36542] shift+click on an existing selection doesn't work right

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed May 5 16:36:31 PDT 2010


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





--- Comment #5 from Ojan Vafai <ojan at chromium.org>  2010-05-05 16:36:31 PST ---
Thanks for the quick review!

> > +            if (distanceToStart < distanceToEnd)
> > +                newSelection = VisibleSelection(pos, end);
> > +            else
> > +                newSelection = VisibleSelection(start, pos);
> 
> I think it's important that the end that moved due to the
> click is the "extent", so that shift-arrow keys modify that side of the
> selection. I believe that means we should have VisibleSelection(end, pos)
> rather than VisibleSelection(pos, end).

I totally meant to do that. Just lost track of it. 

> I'd like to see a test case that covers that part of the behavior as well. I'm
> going to say r=me on this as-is, but I hope you go the extra mile and make the
> refinement I mention above.

np. I'll extend the test to check that the anchor/focus of the selection is
correct after each shift-click.

> Hmm, it also seems like the behavior in NSTextView is:
> 
>     if (distanceToStart <= distanceToEnd)
> 
> because it seems to move the start of the selection, not the end, when there's
> a tie.

Good catch. Will fix.

(In reply to comment #4)
> (In reply to comment #0)
> > The correct Mac behavior is to shrink whichever end of the selection is closest
> > to where you clicked. Windows/Linux have a different expected behavior (the
> > extent of the selection should always be moved on shift+click) that is
> > addressed by bug 25195.
> 
> You say “shrink” specifically here, but isn't this rule and this code also used
> to extend selections?

Will fix.

-- 
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