Closed Bug 86476 Opened 24 years ago Closed 24 years ago

ubercaret appears on multi-line text block

Categories

(MailNews Core :: Composition, defect, P3)

x86
All
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.5

People

(Reporter: dneri98, Assigned: mozeditor)

References

Details

(Whiteboard: [caret])

Build 2001-06-09-20, Win2k sp2 Steps to reproduce: 1. Open MailNews 2. View a message with preformat (fixed width) text 3. Click-Drag and copy a sampling 4. Create a new message 5. Paste sampling 6. Go to beginning and/or end of line with shortcuts CTRL+END/HOME Expected: Goes to beginning/end of the line Actual: Creates a cursor in height equal to the number of lines of text copied (i.e. 5 lines would make a cursor 5 lines tall)
reassign to nbaca, ninoschka, I assigned this bug to you since this was caused by shortcut keys. Please reassign this to esther if you think this is composition specific. Because esther tests this part of composition.
QA Contact: sheelar → nbaca
Build 2001-06-18-04: WinMe I was unable to duplicate the problem. Can you try a newer build? This is a scenario that I tried: - Created a message with 4 lines using a fixed width - Send the message back to the same account - In the message pane I right clicked and used the context menu to Copy - Created a new message and selected Edit|Paste Results: In all cases the cursor appeared normal. Ctrl+Home moved the cursor to the beginning of the first line. Ctrl+End moved the cursor to the end of the last line. Home moved the cursor to the beginning of the current line. End moved the cursor to the end of the current line.
I haven't been able to reproduce it since, but I guarantee this behavior existed at one time. Hard to repro.
Yes! (hehe) I was able to reproduce this AGAIN with build 2001-06-26-11 on Win98! Here's new steps to see if this helps: 1. Set 3-pane view, and display a message in the bottom pane. 2. Click-drag and select some text (happens to be fixed width in my example) 3. Right click to pull up context menu and copy 4. Create a new message 5. Go directly to the message body. 6. (Since no context menu appears on right click,) go to Edit>Paste. Result: I immediately saw a cursor blinking (and still is actually) as many lines tall as my message. Pressing LEFT and RIGHT moved the cursor past the entire block of text as if it were one object. SHIFT+LEFT/RIGHT to select text selected the entire block, again as if it were one object (but correctly selected letter-for-letter). But as soon as I pressed UP, the cursor reset to home position and its normal size. Marking OS as all since there's no "Win/All" option...Change it if you think it's wrong but at least it will grab some attention. Since I've seen this twice in two separate clean installs, should this be confirmed as NEW?
OS: Windows 2000 → All
Changing summary.
Summary: Multi-line cursor with CTRL+END/CTRL+HOME → Multi-line text block treated as one object
More brainstorming... I think this involves the <PRE> tag.
Setting to New since you were able to reproduce this bug. Esther, can you try to reproduce? Sujay, have you heard of this problem in Composer?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I haven't seen this in composer...
Build 2001-06-27-08: WinMe I can reproduce the problem after copying and pasting a bullet list. This might be a duplicate of bug# 88301?
Um, I wouldn't consider a bug opened ten days before as a duplicate. Perhaps the other way around... It appears that any special formatting, i.e. <blockquote> or <pre> is causing the entire block to be treated as one object on one line. Moving to a different line remedies the problem.
reassign to editor
Assignee: ducarroz → beppe
yes, that would be called an ubercaret, and we are aware of the issue. This is just another instance of the caret snapping to the element/parent element and not to the end of the element/last instance. reviewed and approved
Assignee: beppe → jfrancis
Priority: -- → P3
Summary: Multi-line text block treated as one object → ubercaret appears on multi-line text block
Whiteboard: [caret]
Target Milestone: --- → mozilla0.9.3
see patch for this and other bugs attached to bug 83918
Status: NEW → ASSIGNED
Whiteboard: [caret] → [caret] fix in hand; need r=,sr=
*** Bug 88301 has been marked as a duplicate of this bug. ***
*** Bug 89275 has been marked as a duplicate of this bug. ***
*** Bug 92482 has been marked as a duplicate of this bug. ***
Missed 0.9.3.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
clearing the nsbranch keyword so as not to be confused with the current set of nsbranch bugs.
Keywords: nsBranch
Target Milestone: mozilla0.9.4 → mozilla0.9.5
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Whiteboard: [caret] fix in hand; need r=,sr= → [caret]
Build 2001-08-29-04: WinMe, Mac 9.04 Build 2001-08-31-10: Linux RH 6.2 Verified Fixed.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.