334256 - Caret position not correct around the start of a "pre" line.

Status: RESOLVED FIXED

(Core :: DOM: Selection, defect)

Description

[Max]

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

When using Javascript to set the caret to the start of a new line in "pre" text the caret shows incorrectly at the end of the previous line.
(Look at the source of the test file for details.)

Reproducible: Always

Steps to Reproduce:
Use Javascript to set the caret to the end of a "pre" line.
(Refer to test file for Javascript code.)
Actual Results:  
Caret shows at end of previous line.

Expected Results:  
Caret should show at start of line.

This is an annoying bug. It makes editing of "pre" text very confusing if you don't understand the bug because the caret appears to jump over the first character of each line. Difficult to see an easy Javascript workaround for this.

Comment 1

[Uri Bernstein]

Confirming on trunk:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060415 Firefox/3.0a1

Comment 2

[Uri Bernstein]

We probably need to set the hint (to HINTRIGHT) somewhere, but I'm not sure where. Perhaps in nsTypedSelection::setAnchorFocusRange()?

Robert, Blake - ideas?

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I guess so.

Maybe the thing to do is to HINTRIGHT if the anchor is moved earlier in the document, and HINTLEFT if the anchor is moved later.

Comment 4

[Uri Bernstein]

I don't think so. Specifically, In this testcase, I would expect setting the selection to offset 5 to move the caret to the beginning of the second line, regardless of where it was previously.

I can't think of a case where HINTLEFT would yield the expected result, except perhaps for the bidi case (between reverse-direction frames), where either hint would be equally "correct", IMO.

We just have to make sure that wherever we're setting the hint only affects programmatic changes to the selection, and doesn't interfere with the other use cases (arrows, mouse, typing, etc.).

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yeah, OK.

It looks like the only places calling setAnchorFocusRange to something non-empty are AddRange, RemoveRange and Collapse, none of which should have reasonable expectations about the hint afterwards.

Comment 6

[Uri Bernstein]

Attachment: patch

Comment 7

[Uri Bernstein]

Checked in:
Checking in layout/generic/nsSelection.cpp;
/cvsroot/mozilla/layout/generic/nsSelection.cpp,v  <--  nsSelection.cpp
new revision: 3.228; previous revision: 3.227
done

Comment 8

[Uri Bernstein]

*** Bug 333276 has been marked as a duplicate of this bug. ***

Comment 9

[Uri Bernstein]

*** Bug 327653 has been marked as a duplicate of this bug. ***

Comment 10

[Uri Bernstein]

*** Bug 356034 has been marked as a duplicate of this bug. ***

Comment 11

[Cacycle]

This bug has reappeared or is still there in SeaMonkey 1.1.11, but is absent in Firefox Firefox/3.0.1.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 MultiZilla/1.8.3.4e SeaMonkey/1.1.11

Comment 12

[Uri Bernstein]

(In reply to comment #11)

SeaMonkey 1.1.x is based on Gecko 1.8.1. This bug was only fixed for Gecko 1.9.0, hence the fix is not yet available in SeaMonkey.