Closed Bug 335159 Opened 18 years ago Closed 18 years ago

Print: Line break is shown as escaped <BR> after HTML export

Categories

(Calendar :: Internal Components, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: damian.publicemail, Assigned: jminta)

References

()

Details

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2

end of line is visible as <BR> on print preview and printed paper

Reproducible: Always

Steps to Reproduce:
1. create new event, description must include end of line sign (just press enter), eg:

first line [ENTER]
second line

2. print event
Version: unspecified → Trunk
Attached image screenshot —
Confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060426 Mozilla Sunbird/0.3a1+.

A line break (e.g. in description field) is converted to <br> tag during html export for printing. But this tag is than escaped to &lt;br&gt; resulting in the visible <br> and not the expected break.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: print: end line visible as <BR> → Print: Line break is shown as escaped <BR> after HTML export
The bugspam monkeys have struck again. They are currently chewing on default assignees for Calendar. Be afraid for your sanity!
Assignee: base → nobody
I can't really fix this until e4x gets its act together (bug 331145).
Depends on: 331145
jminta: bug 331145 doesn't appear to be about e4x.  Is that really the bug # you intended?
(In reply to comment #5)
> jminta: bug 331145 doesn't appear to be about e4x.  Is that really the bug #
> you intended?
> 
I promise to learn how to use mac keyboards.  Bug 336921 was the number that should have been copied.
Depends on: 336921
No longer depends on: 331145
Attached patch actually append children, don't replace (obsolete) — — Splinter Review
The original code included the quoted <BR>, when really we should be appending a new <br/> child for each line.  (Note that this patch will look weird in branch builds until the blocking bug lands 1.8)  mrbkap said he *badly* wanted to see this patch, so I'm asking him for first-review.
Assignee: nobody → jminta
Status: NEW → ASSIGNED
Attachment #230829 - Flags: second-review?(mvl)
Attachment #230829 - Flags: first-review?(mrbkap)
Attachment #230829 - Flags: first-review?(mrbkap) → first-review+
Comment on attachment 230829 [details] [diff] [review]
actually append children, don't replace

>+                var lines = desc.split('\n');
>+                for each (var line in lines) {
>+                    descnode.div[1].appendChild(line);
>+                    if (line != lines[lines.length]) {
That seems to be asking for trouble. What if one line happens to be equal to the last line?
You really want to use the good old index-based for-loop, so you can simply compare the index of the line with the length.
Attachment #230829 - Flags: second-review?(mvl) → second-review-
Attached patch append children, v2 — — Splinter Review
Carrying forward first review, patch updated to reflect previous comments.
Attachment #230829 - Attachment is obsolete: true
Attachment #231456 - Flags: second-review?(mvl)
Attachment #231456 - Flags: first-review+
Comment on attachment 231456 [details] [diff] [review]
append children, v2

r=mvl
Attachment #231456 - Flags: second-review?(mvl) → second-review+
Whiteboard: [checkin needed]
Patch checked in on MOZILLA_1_8_BRANCH and trunk

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed]
verified, works prity good
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: