Textbox attribute "multiline" seems broken

RESOLVED FIXED in mozilla1.8alpha3

Status

()

Core
XUL
P3
normal
RESOLVED FIXED
14 years ago
14 years ago

People

(Reporter: Xanthor Sccas, Assigned: peterv)

Tracking

Trunk
mozilla1.8alpha3
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040706 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040706 Firefox/0.8.0+

We can't write different lines in textboxes, even with the appropriate attribute
: multiline.

Reproducible: Always
Steps to Reproduce:
1. Find a textbox with multiline attribute¹
2a. Write words, and try to press enter
2b. Copy and paste some text with newlines
Actual Results:  
1a. No new line is created
1b. The new lines are deleted

Expected Results:  
Newlines

¹ : for exemple you can use the ChromEdit extension...

This is a regression. I can see it in Mozilla 1.8a2, but also in a 2004-07-06 build.

I've noticed that bug 251193, comment 1 talk about that bug (that's why I set OS
to all), but I can't find the original bug :¬(

Comment 1

14 years ago
Confirming bug, the regression occured between 2004-06-24-06 and 2004-06-25-07.
The problem sounds very much like bug 249665 which was a regression from
bug 236408 which seems to be in the interval...
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 2

14 years ago
Bug 249665 was debug only.
(Assignee)

Comment 3

14 years ago
Fallout from bug 236408, nsEditor::CreateHTMLContent needs to be able to deal
with any type of document. Right now we create a BR element in the XUL namespace
if the document is a XUL document.
(Assignee)

Updated

14 years ago
Assignee: jag → peterv
Priority: -- → P3
Target Milestone: --- → mozilla1.8alpha3
(Assignee)

Comment 4

14 years ago
Created attachment 154033 [details] [diff] [review]
v1 (checked in)
(Assignee)

Comment 5

14 years ago
Comment on attachment 154033 [details] [diff] [review]
v1 (checked in)

This fixes it. However, I'm not convinced that we've found the best API for
nsIDocument::CreateElem. I wonder if we should just add
nsIHTMLDocument::CreateHTMLElem, which would create the right *HTMLElement with
the correct namespace (_None or _XHTML), and keep CreateElem for creating XML
elements with as arguments namespace, prefix and localname.
Attachment #154033 - Flags: superreview?
Attachment #154033 - Flags: review?
(Assignee)

Comment 6

14 years ago
Comment on attachment 154033 [details] [diff] [review]
v1 (checked in)

This fixes it. However, I'm not convinced that we've found the best API for
nsIDocument::CreateElem. I wonder if we should just add
nsIHTMLDocument::CreateHTMLElem, which would create the right *HTMLElement with
the correct namespace (_None or _XHTML), and keep CreateElem for creating XML
elements with as arguments namespace, prefix and localname.
Attachment #154033 - Flags: superreview?(jst)
Attachment #154033 - Flags: review?(jst)
(Assignee)

Updated

14 years ago
Attachment #154033 - Flags: superreview?
Attachment #154033 - Flags: review?
Comment on attachment 154033 [details] [diff] [review]
v1 (checked in)

r+sr=jst
Attachment #154033 - Flags: superreview?(jst)
Attachment #154033 - Flags: superreview+
Attachment #154033 - Flags: review?(jst)
Attachment #154033 - Flags: review+

Comment 8

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

Updated

14 years ago
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 9

14 years ago
Comment on attachment 154033 [details] [diff] [review]
v1 (checked in)

Resolve Bug, or are we leaving open for better API?
Attachment #154033 - Attachment description: v1 → v1 (checked in)
forgive me, missed that it said fixed :(
You need to log in before you can comment on or make changes to this bug.