41865 - First single space not shown in editor

Status: VERIFIED INVALID

(Core :: Layout, defect, P1)

Description

[Ben Bucksch (:BenB)]

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.

Comment 1

[Ben Bucksch (:BenB)]

...to fix this bug.

Comment 2

[rubydoo123]

assigning to jfrancis

Comment 3

[Joe Francis]

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.

Comment 4

[Joe Francis]

cc'ing me

Comment 5

[Nisheeth Ranjan]

Reassigning to buster... (Triaging clayton's bug list).

Comment 6

[Ben Bucksch (:BenB)]

> 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

[Joe Francis]

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".

Comment 8

[Peter Trudelle]

Not dogfood, but will take fix for nsbeta2 if done by 6/22

Comment 9

[buster]

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

[Joe Francis]

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.

Comment 11

[buster]

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.

Comment 12

[Joe Francis]

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

Comment 13

[Ben Bucksch (:BenB)]

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.

Comment 14

[Ben Bucksch (:BenB)]

my whitespace has been aten. Correct is:

[...]
this would have to render as

foo
 bar
[...]

Comment 15

[Chris Petersen]

Marking verified invalid.

Comment 16

[Daniel Veditz [:dveditz]]

Adding keyword to bugs which already show a nsbeta2 triage value in the status 
whiteboard so the queries don't get screwed up.