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>.
<rdar://problem/6764354>
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?
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?
(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.
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).
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.
Then we can use DumpRenderTree to have separate tests for each platform's modes.
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.
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. :(
Created attachment 29608 [details] work in progress
Created attachment 29664 [details] patch
http://trac.webkit.org/changeset/42732