Bug 25162 – REGRESSION (r41176-r41242): Drag-selection above/below the line does not select to beginning/end

• Status: RESOLVED
• Resolution: FIXED
• Component: HTML Editing

[Darin Adler]

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

[Darin Adler]

<rdar://problem/6764354>

[Darin Adler]

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?

[Eric Seidel (no email)]

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?

[Darin Adler]

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

[Ojan Vafai]

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

[Darin Adler]

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.

[Darin Adler]

Then we can use DumpRenderTree to have separate tests for each platform's modes.

[Darin Adler]

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.

[Eric Seidel (no email)]

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. :(

[Darin Adler]

Created attachment 29608 [details]
work in progress

[Darin Adler]

Created attachment 29664 [details]
patch

[Darin Adler]

http://trac.webkit.org/changeset/42732