Bug 25162 - REGRESSION (r41176-r41242): Drag-selection above/below the line does not select to beginning/end
Summary: REGRESSION (r41176-r41242): Drag-selection above/below the line does not sele...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P1 Normal
Assignee: Darin Adler
URL:
Keywords: InRadar, Regression
Depends on:
Blocks:
 
Reported: 2009-04-13 14:13 PDT by Darin Adler
Modified: 2010-05-27 14:05 PDT (History)
5 users (show)

See Also:


Attachments
work in progress (13.18 KB, patch)
2009-04-19 14:53 PDT, Darin Adler
no flags Details | Formatted Diff | Diff
patch (196.88 KB, patch)
2009-04-21 15:38 PDT, Darin Adler
mitz: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Darin Adler 2009-04-13 14:13:09 PDT
When dragging to select text, dragging below (above) the last line should select through the end (beginning), but it does not.

* STEPS TO REPRODUCE
1. Go to <data:text/html,lorem%20ipsum>
2. Start dragging from between the words, and drag downwards

* RESULTS
The extent of the selection tracks the mouse pointer’s horizontal position. It should immediately snap to the end of the paragraph.

Dan strongly suspects <http://trac.webkit.org/changeset/41191>.
Comment 1 Darin Adler 2009-04-13 14:34:25 PDT
<rdar://problem/6764354>
Comment 2 Darin Adler 2009-04-13 14:36:57 PDT
It's clear reading the code why this happens. The positionForPointWithInlineChildren function intentionally hit tests nodes by passing them the real X, and a fake Y based on the position of the node. For a text node, this gives the effect we're seeing.

In the older code, this was limited to certain cases, but now happens in any case where we hit a block and are trying to figure out which of its inline children was hit. What's the rule we're trying to implement?
Comment 3 Eric Seidel (no email) 2009-04-13 14:50:29 PDT
We're trying to emulate Word behavior where when you click below a line, your selection starts at the x offset of your click, instead of at the end of line.  Correct, ojan?
Comment 4 Darin Adler 2009-04-13 15:06:10 PDT
(In reply to comment #3)
> We're trying to emulate Word behavior where when you click below a line, your
> selection starts at the x offset of your click, instead of at the end of line. 

This is starting to look like a platform difference. On Windows, applications consistently seem to behave this way. On Mac OS X, that's a quirk of Word that’s not shared by any other major Mac OS X application.
Comment 5 Ojan Vafai 2009-04-13 15:22:51 PDT
Yeah, this does look platform specific. Related to this is what should happen when you hit up/down arrow at the first/last line of an editable area. Which is to say, on Mac it should go to the beginning/end of the line and on windows it should do nothing (don't know about Linux).
Comment 6 Darin Adler 2009-04-13 15:38:00 PDT
For regression testing purposes, I think we should probably make these behaviors be controlled by a setting, and have it default to the appropriate value depending on the platform.
Comment 7 Darin Adler 2009-04-13 15:38:18 PDT
Then we can use DumpRenderTree to have separate tests for each platform's modes.
Comment 8 Darin Adler 2009-04-13 15:39:15 PDT
What's unfortunate here is that it was unconditionally following the Mac OS X style before, but now it's unconditionally following Windows style; that's not great for Safari on Mac.
Comment 9 Eric Seidel (no email) 2009-04-13 15:54:04 PDT
What's extra unfortunate is that Ojan and I didn't realize that this was a platform-specific behavior when fixing it to match Word here. :(
Comment 10 Darin Adler 2009-04-19 14:53:31 PDT
Created attachment 29608 [details]
work in progress
Comment 11 Darin Adler 2009-04-21 15:38:33 PDT
Created attachment 29664 [details]
patch
Comment 12 Darin Adler 2009-04-21 16:30:41 PDT
http://trac.webkit.org/changeset/42732