First single space not shown in editor

VERIFIED INVALID

Status

()

Core
Layout
P1
normal
VERIFIED INVALID
18 years ago
18 years ago

People

(Reporter: BenB, Assigned: buster)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [dogfood-][nsbeta2+][6/22])

(Reporter)

Description

18 years ago
Reproduce:
1. Open Mailnews HTML composer
2. *Type* exactly the following lines:

foo
 foo
  foo

3. Look at the result as shown in the canvas
4. Do Debug|OutputHTML

Actual result:
- After 3., you see

foo
foo
  foo

- After 4., you see in part something like

foo<br> foo<br>&nbsp; foo

Expected result:
Editor's policy is to preserve all spaces the user enters. So, I'd expect

- After 3.

foo
 foo
  foo

- After 4. in part

foo<br>&nbsp;foo<br>&nbsp; foo

Additional comments:
I actually found this bug in the Mailnews flowed converter first, where we
emulate the editor behaviour. So, I'd be interested in the algorithm you use.
(Reporter)

Comment 1

18 years ago
...to fix this bug.

Comment 2

18 years ago
assigning to jfrancis
Assignee: beppe → jfrancis
Target Milestone: --- → M17

Updated

18 years ago
Summary: First single space not shown → First single space not shown in editor

Comment 3

18 years ago
spaces are preserved.  The nbsp is a space, in rendering terms.  If we didnt put 
in the nbsp, html would render the two spaces as one.

As for the first space not showing up, this is a new problem, and is a layout 
problem.  The space is there in the content model and should be rendered.

assigning to layout.  nominating for dogfood.  We need this for the editor to 
work properly.
Assignee: jfrancis → clayton
Component: Editor → Layout
Keywords: dogfood
QA Contact: sujay → petersen

Comment 4

18 years ago
cc'ing me

Comment 5

18 years ago
Reassigning to buster... (Triaging clayton's bug list).
Assignee: clayton → buster
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Priority: P3 → P1
(Reporter)

Comment 6

18 years ago
> As for the first space not showing up, this is a new problem, and is a layout
> problem.  The space is there in the content model and should be rendered.

I am not an layout master, but I'd expect it *not* to render, because I consider
both "<br>" and " " to be whitespace and thus the space to be collapsed.

Comment 7

18 years ago
newlines are whitespace.  <br> is a break node.  text inserted into the editor 
undergoes a conversion, where newlines are converted to break nodes.  So if you 
type or paste in "foo\n foo\n  foo", you get, from a content perspective:
<text node "foo">
<br>
<text node " foo">
<br>
<text node "{nbsp} foo">

where I use {nbsp} to stand for 0xA0 (I think), which is the byte code used by 
layout for nbsp.  

If we used actual newline characters instead of break nodes, you wouldn't even 
see the foo's draw on different lines.  Newlines only cause a new line to be 
started if there is a "white-space: pre" style in force.

As it happens, even if there is a pre style in force, we still convert newlines 
to break nodes; but that's a different story to painful to be recounted here.  
:-P

Anyway, the break node causes any whitespace after it to be significant.  That's 
why we don't need an nbsp prior to the second "foo".

Updated

18 years ago
Whiteboard: [dogfood-][nsbeta2+][6/22]

Comment 8

18 years ago
Not dogfood, but will take fix for nsbeta2 if done by 6/22
(Assignee)

Comment 9

18 years ago
I'm not quite with you on this one, Joe.
Given this input:

foo<br> foo<br>&nbsp; foo

Nav4, IE5, and gecko all render the same:

foo
foo
  foo


and given the input:

foo<br>&nbsp;foo<br>&nbsp; foo

all 3 render:

foo
 foo
  foo

So I don't see any bug.  Gecko is compatible with the 2 main browsers.

Comment 10

18 years ago
Wow.  I wonder if the behavior changed recently.  If not I'm absolutely astounded 
that no one noticed this until now.  

This is going to complicate the whitespace conversion.  Waaah.  

I can't find anything in the 4.0 spec that addresses this definitively.  A <br> 
node is definitely not whitespace, and it makes no mention of collapsing 
whitespace to nothing except for at the beginning of a block (like leading 
whitespace in a <p>).  

Oh well.  Close it out I guess.  I'll open a new bug against myself to add to the 
editor's whitespace logic: considering the presence of <br>s adjacent to other 
whitespace.
(Assignee)

Comment 11

18 years ago
Joe: you say the HTML 4 spec does specify that leading whitespace is compressed 
to nothing at the beginning of a block.  Well, the BODY is a block, so AFAICT 
we're doing the right thing.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID

Comment 12

18 years ago
I agree that layout is doing the right thing, but the space in question is not at 
the start of a block.  It is after a break, which is an inline element.  I 
haven't been able to find any rational in the spec for this behavior, but if 
everybody's doin' it, it must be good!  :-P
(Reporter)

Comment 13

18 years ago
jfrancis, IÄm not yet completely sure which argumentation tofollow, but consider
this:

foo<br>
bar

Between <br> and bar, there is whitespace. So, if whitespace after <br> is not
removed, this would have to render as

foo
bar

Propably not what the author intended.

> I'll open a new bug against myself to add to the 
> editor's whitespace logic

Please cc me.
(Reporter)

Comment 14

18 years ago
my whitespace has been aten. Correct is:

[...]
this would have to render as

foo
 bar
[...]

Comment 15

18 years ago
Marking verified invalid.
Status: RESOLVED → VERIFIED
Adding keyword to bugs which already show a nsbeta2 triage value in the status 
whiteboard so the queries don't get screwed up.
Keywords: nsbeta2
You need to log in before you can comment on or make changes to this bug.