Closed Bug 252589 Opened 20 years ago Closed 20 years ago

Textbox attribute "multiline" seems broken

Categories

(Core :: XUL, defect, P3)

x86
All
defect

Tracking

()

RESOLVED FIXED
mozilla1.8alpha3

People

(Reporter: xanthor+bz, Assigned: peterv)

References

()

Details

Attachments

(1 file)

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 :¬(
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
Bug 249665 was debug only.
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: jag → peterv
Priority: -- → P3
Target Milestone: --- → mozilla1.8alpha3
Attached patch v1 (checked in)Splinter Review
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?
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)
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+
*** Bug 251193 has been marked as a duplicate of this bug. ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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.

Attachment

General

Created:
Updated:
Size: