Closed Bug 13647 Opened 25 years ago Closed 25 years ago

extra newline inserted

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: buster, Assigned: harishd)

References

(
URL
)

Details

in the editor, open a file with this content:

<html><body>1234567890abcdefg</body></html>

make 2-9 bold, then 2-8 italic

save.

you get an extra newline in the output file between the <b> and the <i>:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html"; charset="ISO-8859-1">

</head>


<body>1<b>
<i>2345678</i>9</b>0abcdefgh</body>
</html>

this is bad because the whitespace between the <b> and <i> is significant, and
shows up in the broswser (4.x as well as 5.0)
Status: NEW → ASSIGNED
Target Milestone: M11
Probably a side-effect of my new newline insertion code.  The formatting code
needs to distinguish between inline and block tags, and not kick in for inline
tags.  This was high on my to-do list anyway, so it's good to have a bug filed
as a reminder.
Assignee: akkana → harishd
Status: ASSIGNED → NEW
Update: No, this has nothing to do with my new formatting code, which isn't even
switched on yet.  Here's what's happening: when two inline tags come in
succession, for some reason the parser thinks it sees a whitespace token,
whereas with only one tag, it doesn't.

In this case, the relevant part of the XIF looks like this:

<container isa="b">
<container isa="i">
<content>2345678</content>

yet for some reason, the parser is calling nsXIFDTD::HandleWhiteSpaceToken and
passing in a newline between the b tag and the i tag.  If the i tag isn't there,
the parser doesn't call HandleWhiteSpaceToken, even though the XIF still has the
same structure of one XIF tag per line.

Incidentally, you can use the editor debug menu items "Output HTML" and "Output
XIF" to simplify testing this; no need to save to a file.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
in XIFconverter, by default, we were inserting a newline at the end of a tag.

FIXED now.
Status: RESOLVED → VERIFIED
verified in 10/13 build.
You need to log in before you can comment on or make changes to this bug.