Bug 19490 – caret is not displayed in proper location when non-wrappable-word exceeds the boundary of its container.

• Component: New Bugs
• Status: ASSIGNED

[Anantha Keesara]

I. Steps:
 -----------
 
 1.  Launch Safari
 
 2.  Open the test case
 
 3.  Hold down the j key (until scrollbars appear)
 
 4.  Hold down the k key
 
 
 II. Issue:
 -----------------
 The frame should scroll to keep your caret visible (and you should see k's). Instead it shows a line of j's with the caret (not flashing) 2 letters from the right edge of the frame.
 
 
 III. Other browsers:
 -----------------------
 
 FF3 : Ok 
 Opera 9.27: Ok
 
 
 IV. Safari nightly tested: version 3.1.1(525.17 )- r34278.
 
 Not working properly on Safari.
 
 
 
 V. Safari screenshot : Avalible

[Anantha Keesara]

Created attachment 21631 [details]
Screenshot

[Anantha Keesara]

Created attachment 21641 [details]
reduction

[Victor Wang]

Change the title as this could happen to other editable contents.

The problem is the calculation of caret location in
RenderText::localCaretRect is incorrect when non-wrappable word
typed exceeds the boundary of its container and the editable content
is set to no word break. When typing new chars in this case, the                                                                                      
container does not scroll and the caret stops moving, so the
caret is not in the position where the new chars are added and                                                                                 
the new chars added may not be visible.

IE and Firefox work fine in this case.

[Victor Wang]

Created attachment 40886 [details]
Proposed Patch

[Eric Seidel (no email)]

Comment on attachment 40886 [details]
Proposed Patch

Do these tests need rendering tree dumps and pixel results or can we cover this code with a dumpAsText test?

[Victor Wang]

I was trying to just use DumpAsText, but can't find ways to get the caret location in test. The selection location and size are correct and the issue here is the caret's position. Seems to me we have to use the rendering dump tree and pixel results.

[Victor Wang]

Created attachment 41119 [details]
Update proposed patch

Remove Win baselines from the patch. The Win baselines are same as mac versions if the fonts are installed correctly.

[Dave Hyatt]

Comment on attachment 41119 [details]
Update proposed patch

The line in this test:

window.getSelection().setPosition(body, body.offsetLeft + body.offsetWidth);

makes no sense.  setPosition takes a range offset and not a pixel offset.

[Victor Wang]

Created attachment 41164 [details]
Updated patch

Fixed setPosition in caret-scroll-iframe-designmode.html.

[Dave Hyatt]

Comment on attachment 41164 [details]
Updated patch

My own opinion (and I could be wrong) is that the entire if statement is wrong, and that the else code should just run all the time.

[Enrica Casucci]

I agree with David's comment. The entire if block can be removed and execute always the block in the else branch. I've verified that your test case passes.

[Ryosuke Niwa]

This bug is causing editing/selection/designmode-no-caret.html to fail on chromium port.

[Victor Wang]

I recall that Enrica said there are some tests fail on snow leopard. Not clear to me whether they are related to the change...