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

RESOLVED FIXED in mozilla1.9alpha1

Status

()

RESOLVED FIXED
13 years ago
10 years ago

People

(Reporter: bugs, Assigned: uriber)

Tracking

({testcase})

Trunk
mozilla1.9alpha1
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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.
(Assignee)

Comment 1

13 years ago
Confirming on trunk:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060415 Firefox/3.0a1
Assignee: nobody → selection
Status: UNCONFIRMED → NEW
Component: Keyboard Navigation → Selection
Ever confirmed: true
Keywords: testcase
OS: Windows ME → All
Product: Firefox → Core
QA Contact: keyboard.navigation
Hardware: PC → All
Version: unspecified → Trunk
(Assignee)

Comment 2

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

Robert, Blake - ideas?
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.
(Assignee)

Comment 4

13 years ago
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.).
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.
(Assignee)

Comment 6

13 years ago
Created attachment 218987 [details] [diff] [review]
patch
Assignee: selection → uriber
Status: NEW → ASSIGNED
Attachment #218987 - Flags: superreview?(roc)
Attachment #218987 - Flags: review?(roc)
Attachment #218987 - Flags: superreview?(roc)
Attachment #218987 - Flags: superreview+
Attachment #218987 - Flags: review?(roc)
Attachment #218987 - Flags: review+
(Assignee)

Comment 7

13 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha
(Assignee)

Updated

13 years ago
Depends on: 336590
(Assignee)

Comment 8

12 years ago
*** Bug 333276 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 9

12 years ago
*** Bug 327653 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 10

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

Updated

12 years ago
Depends on: 353061
(Assignee)

Updated

12 years ago
No longer depends on: 353061

Comment 11

10 years ago
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
(Assignee)

Comment 12

10 years ago
(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.
You need to log in before you can comment on or make changes to this bug.