[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