25680 - space before <br> at end of line with no room left gets wrapped to next line {ll} [INLINE]

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[fantasai]

Overview Description: 

	At certain window widths, Mozilla adds an extra line break before <BR>.

Steps to Reproduce: 
	(Will be attaching a test case)

	1) Open up Line Break Test in Mozilla, but don't maximize it.
	2) Adjust the width of the window until the first line 
	    breaks right after the period. 
	    On Test A, you'll see everything line up.
	3) *Slowly* narrow the window. 
	    At one point, the sentence after the break (<BR>) will snap down.
	4) If you keep narrowing it, the line will return.
	5) The window needs to be readjusted for Tests B and C.
	6) Test B behaves the same way--the only difference 
	    is that it has one line of text.
	7) Test C behaves as it should.

	* The blue line represents the edge of the DIV, nothing more.

Build Date & Platform Bug Found: 

	Jan. 17, 2000 (Raptor) on WinNT4 (600x800 screen res)

Additional Builds and Platforms Tested On: 

	Jan. 28, 2000 on WinNT4

Comments: 

	 Test A has a line break before the <BR>; Test B has a space. 
	Test C, which behaves correctly, has no whitespace before the <BR>. 

	 Mozilla seems to be wrapping the <BR>'s line break to the next line, 
	which it should not do.

Comment 1

[fantasai]

Attachment: Line Break Test

Comment 2

[Mats Palmgren (inactive)]

IE5 has the exact same behaviour. I think this is how it's supposed to work.
The space or line-break before the <BR> is significant, and it's this character
that is moved down causing the empty line.

Comment 3

[troy]

Re-assigning to Kipp's bug list. mats is probably right, although I don't enough 
of the subtleties to say for sure

Comment 4

[buster]

post-beta issue

Comment 5

[buster]

mine! mine mine mine!  all mine!  whoo-hoo!

Comment 6

[buster]

need to examine this bug to see if it's valid, or if we're behaving properly

Comment 7

[buster]

redistributing bugs across future milestones, sorry for the spam

Comment 8

[buster]

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration. 

Comment 9

[Hixie (not reading bugmail)]

Correcting summary so that I don't get worried when I see it marked Future...

Comment 10

[Hixie (not reading bugmail)]

This was also reported in bug 53985 which broke out of bug 13097.

The code fragment:

   <div>
     some text just long enough to fit on the line <br> some more text
   </div>

...renders as:
  
   some text just long enough to fit on the line
   
   some more text

Note the extra blank line.

This is easily reproducable if you use images instead of text, and a fixed
width DIV or table cell to hold them in.

STEPS TO REPRODUCE:
  See test case: 
  http://www.bath.ac.uk/%7Epy8ieh/cgi/development/tests/linemodel1?mode=standard

EXPECTED RESULTS:
  Only a few pixels between each line, except the last one in each block 
  (<br><br>) which should have a whole blank line.

ACTUAL RESULTS:
  As expected except for the " <br>" cases when the width of the line is equal
  to or less than the length of the "text" (actually an image) on the line.

TESTED ON:
  Known to be broken on All/All.

RELEASE NOTE ITEM:
   Mozilla currently does not ignore whitespace before a <br>, which in
   certain rare cases can cause an extra blank line to be inserted in the
   rendering. See bug 25680 for more details. Workaround: remove any spaces
   before a <br> element, or avoid use of this element altogether.

Comment 11

[Hixie (not reading bugmail)]

*** Bug 53985 has been marked as a duplicate of this bug. ***

Comment 12

[ekrock's old account (dead)]

Nom. nsbeta1. We're messing up on the handling of legacy content here.

Comment 13

[Kevin McCluskey (gone)]

Build reassigning Buster's bugs to Marc.

Comment 14

[Boris Zbarsky [:bzbarsky]]

*** Bug 137957 has been marked as a duplicate of this bug. ***

Comment 15

[Christopher Hoess (gone)]

The URL broke. What specification, exactly, is being violated here?

Comment 16

[Hixie (not reading bugmail)]

New test URI:
   http://software.hixie.ch/utilities/cgi/test-tools/linemodel1?mode=standard

This is WORKSFORME now.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Verified worksforme, based on attachment 4708 [details].

Comment 18

[fantasai]

Test B still fails. (build: 2003021880 Win2K) Reopening. Also, Stanimir Stamenkov
has posted a nice testcase on n.p.m.layout, which I'm hoping will find its way
here, with comments and all.

Comment 19

[crook]

Yes
Test B fails again (W2K Pro)
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

Comment 20

[Stanimir Stamenkov]

Attachment: Simple test case (one more)

Extra new line when the container is shrink to nearly at the end of a line:

first longer line<br>
second line

and

first longer line
<br>second line

In the second case if you shrink the container nearly the end of the first line
there will be inserted visually an extra new line. However if you consider the
following identical cases:

first line<br>
second longer line

and

first line
<br>second longer line

Shrinking the container nearly the end of the first line doesn't cause an extra
new line to appear between the first and the second one.

Seems if the second line is longer and is already wrapped while reaching the
end of the first one there's no extra blank space inserted.

Comment 21

[Daniel Todd Currie]

I have a pair of stupid websites that might demonstrate the problem more lucidly...

http://dtcurrie.net/brtest/
http://dtcurrie.net/brtest2/

In one of them there is a space between the top two chimp pictures; in the other
there is none.  Yet the only difference between them is a carriage return before
and after the <BR> tag in question.

This bug ocurrs in Mozilla build ID: 2004012505 on Mac v10.3.2.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Please retest in tomorrow's builds?  Bug 132561 should have fixed this.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

I can't find the nightly which fixes this, but the testcases do WFM with the current trunk.