View doesn't scroll to caret on large indent

NEW
Assigned to

Status

()

Core
Editor
P1
normal
16 years ago
11 years ago

People

(Reporter: Dan McGuirk, Assigned: smontagu)

Tracking

({topembed+})

Trunk
mozilla1.5beta
x86
Windows 2000
topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: edt_x3 EDITORBASE+)

(Reporter)

Description

16 years ago
Open a blank message, and keep hitting the indent button until you've indented
all the way off the side of the screen.  I would expect the view to scroll to
always keep the caret visible, but it doesn't; the caret disappears.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

16 years ago
Keywords: topembed

Updated

16 years ago
Priority: -- → P1
Target Milestone: --- → Future

Updated

16 years ago
Whiteboard: edt_x3

Comment 1

16 years ago
*** Bug 193738 has been marked as a duplicate of this bug. ***

Comment 2

16 years ago
using trunk builds, the scrollbar moves as expected, however, the blinking
cursor disappears once you get to the window's edge. it re-appears once you
start typing.

expected results are that the scrollbar scrolls (as is happening) *and* the
cursor stays visible and adjacent to the rightmost window border.
Keywords: topembed → topembed+
Whiteboard: edt_x3 → edt_x3 EDITORBASE+

Comment 3

16 years ago
Using a current trunk build the horizontal scrollbars are activated, however,
the caret disappears until typing begins.

Comment 4

16 years ago
Just an observation from using composer, it looks like in CSS mode we implement
the indent as a left margin ... it looks like the caret disappears because the
br it attatches to for rendering is pushed out of the bounds of the div
containing it, by the margin ... I'm guessing that the div doesn't think it
needs to resize because brs don't really add width to a line.
QA Contact: sujay → sairuh

Comment 5

15 years ago
Can we have an updated milestone?

Updated

15 years ago
Target Milestone: Future → mozilla1.5beta
Loading balancing bugs -> smontagu
Assignee: kin → smontagu
(Assignee)

Comment 7

15 years ago
This is a combination of what kin said in comment 4 and the code in
nsCaret::GetCaretRectAndInvert() which tweaks the caret position so it doesn't
overhang the frame.

It's really a very special case of the behaviour in bug 105397
(Assignee)

Updated

15 years ago
Depends on: 98564
QA Contact: bugzilla → editor
You need to log in before you can comment on or make changes to this bug.