Closed
Bug 252589
Opened 20 years ago
Closed 20 years ago
Textbox attribute "multiline" seems broken
Categories
(Core :: XUL, defect, P3)
Tracking
()
RESOLVED
FIXED
mozilla1.8alpha3
People
(Reporter: xanthor+bz, Assigned: peterv)
References
()
Details
Attachments
(1 file)
3.15 KB,
patch
|
jst
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
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•20 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•20 years ago
|
||
Bug 249665 was debug only.
Assignee | ||
Comment 3•20 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•20 years ago
|
Assignee: jag → peterv
Priority: -- → P3
Target Milestone: --- → mozilla1.8alpha3
Assignee | ||
Comment 4•20 years ago
|
||
Assignee | ||
Comment 5•20 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•20 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•20 years ago
|
Attachment #154033 -
Flags: superreview?
Attachment #154033 -
Flags: review?
Comment 7•20 years ago
|
||
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•20 years ago
|
||
*** Bug 251193 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•20 years ago
|
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 9•20 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)
Comment 10•20 years ago
|
||
forgive me, missed that it said fixed :(
You need to log in
before you can comment on or make changes to this bug.
Description
•