Open
Bug 212007
Opened 22 years ago
Updated 9 months ago
`insertParagraph` collapses `Selection` after `<div>` which is formatted by the command if the line ends with unknown empty element
Categories
(Core :: DOM: Editor, defect)
Core
DOM: Editor
Tracking
()
NEW
People
(Reporter: david, Unassigned)
Details
(Keywords: testcase)
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030707
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030707
There are still major editing problems in mail composition.
I here attempt to provide a reproducible scenario of how to produce one where
pressing enter at the end of one line sends the cursor to the beginning of the
same line, but if you then type something, it opens up a new line for the text.
Reproducible: Always
Steps to Reproduce:
1.Open the attached html in composer
2.Select the content with CTRL-A and copy it with CTRL-C
3.Open a new message window
4.Select anything there with CTRL-A
5.Paste the previously copied content in there
6.Click the cursor to the end of point 1 in the message text, right after the
question mark.
7.Press enter.
Actual Results:
Notice that the cursor didn't open up a new line as you would expect, but that
the cursor is now at the beginning of the line.
Notice also that you type something, it does open up a new line.
Expected Results:
It should behave as you would expect a text editor to, by opening up a new line
when you press enter.
|
Reporter | |
Comment 1•22 years ago
|
||
|
|
Reporter | |
Comment 2•22 years ago
|
||
Same in Composer, not just in mail composition.
|
||
Comment 3•22 years ago
|
||
.
Assignee: sspitzer → jfrancis
Component: Composition → Editor: Core
Product: MailNews → Browser
QA Contact: esther → sairuh
|
||
Comment 4•22 years ago
|
||
I see this on my Mac Netscape 7.1 build (based on 1.4). I doubt this ever
worked but a more minimal testcase would be helpful here. The textcase given
has lots of ugly MS-isms in it. :-(
Note that typing after pressing return does appear where it should and that
after pressing return the caret is not in the same place as it would be if you
placed the caret before the 1. This is one of those cases where the <br> is
inserted but the line height isn't calculated correctly or something like that.
qawanted since it'd be good to have a more minimal testcase that shows this problem.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
Summary: Text editing problems - pressing return at the end of a line sometimes sends the cursor to the beginning of the same line → Text editing problems - pressing return at the end of a line sometimes sends the cursor to the beginning of the same line [invalid html]
|
||
Updated•19 years ago
|
QA Contact: bugzilla → editor
|
|
||
Updated•19 years ago
|
Assignee: mozeditor → nobody
|
||
Comment 6•5 years ago
|
||
Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.
If you have reason to believe this is wrong, please write a comment and ni :jstutte.
Severity: normal → S4
Priority: -- → P5
|
||
Comment 7•9 months ago
|
||
Within the minimal testcase with setting document.designMode = "on", the DOM from:
<body>
Click Here ->[]<o:p></o:p>
</body>
to:
<body><div>Click Here -><br><o:p><o:p></div>{}
</body>
At least, the DOM should become like:
<body><div>Click Here -></div><div>{}<o:p><o:p><br></div>
</body>
Severity: S4 → S3
Priority: P5 → --
Summary: Text editing problems - pressing return at the end of a line sometimes sends the cursor to the beginning of the same line [invalid html] → `insertParagraph` collapses `Selection` after `<div>` which is formatted by the command if the line ends with unknown empty element
You need to log in
before you can comment on or make changes to this bug.
Description
•