|Summary:||cursor movement and text selection doesn't work with floats|
|Product:||WebKit||Reporter:||Ojan Vafai <ojan>|
|Component:||HTML Editing||Assignee:||Nobody <webkit-unassigned>|
|Severity:||Normal||CC:||darin, enrica, eric, hyatt, michaelthomas, rniwa|
|Version:||528+ (Nightly build)|
|OS:||OS X 10.5|
Description Ojan Vafai 2009-06-22 17:53:11 PDT
Attached test cases coming.
Comment 1 Ojan Vafai 2009-06-22 17:58:59 PDT
Created attachment 31697 [details] test case Two problems in this test case. 1. Click before "1d". Then hold shift and press the down arrow twice. That should select the last line (i.e. the 1d), but instead it selects all the editable content. 2. Click before the "1J". Hit the down arrow 4 times. Note that it never actually moves the cursor down! It moves the cursor *right* by 1 character each time. This is a reduced test case from a bug I just hit in gmail. If you reply to any logged chat in gmail, the HTML looks something like this test case (although with a bunch more markup).
Comment 2 Ojan Vafai 2009-06-22 18:01:34 PDT
CCing people who know about the selection code. I imagine this bug is just a result of us skipping floated elements whenever we see them, but now that I've hit this in the wild (in gmail specifically), it makes me wonder if we should try to do better.
Comment 3 Michael Thomas 2009-12-01 17:08:04 PST
I am able to reproduce this bug without using floats: - Go to the midas demo: http://www.mozilla.org/editor/midasdemo - Enter the following HTML: <div>a</div><span>b</span> - Place the cursor before 'a'. - Hold down shift and press the down arrow. - Note that the entire contentEditable element has been selected. This reproduces using any inline element in the place of the span.
Comment 4 Darin Adler 2009-12-02 10:42:10 PST
(In reply to comment #3) > I am able to reproduce this bug without using floats: What makes that the same bug?
Comment 5 Michael Thomas 2009-12-02 11:30:13 PST
(In reply to comment #4) > (In reply to comment #3) > > I am able to reproduce this bug without using floats: > > What makes that the same bug? The bug I described seems to be a superset of this bug. i.e. the problem is not just floats, but any block element followed by an inline element. Note that the reproduction steps are identical.