194119 - {inc}Paragraph percentage padding based on line-wrapping (CSS padding-left values not recomputed correctly on window resize for block boxes with one and only one inline box child)

Status: RESOLVED DUPLICATE of bug 30802

(Core :: Layout: Block and Inline, defect, P2)

Description

[Graham Yardley]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210

In the example given (to be attached) when paragraphs use the left percentage 
padding and there is no line-wrapping the amount of padding will vary.  The 
padding applied appears to be determine by what the correct padding would if 
the browser width was small enough to cause line-wrapping.  

Reproducible: Always

Steps to Reproduce:
1.Create  P ellemet style with left percentage padding 
P
{
	Padding: 0 0 0 10%;
}
2. Write a small paragraph with a couple of words that will not wrap, and one 
large enough to wrap
3. Vary your browser width

Actual Results:  
The none wrapping parragraphs have different padding than the wrapping ones.  

Expected Results:  
The none wrapping parragraph should have the same padding as the wrapping 
ones.

Comment 1

[Graham Yardley]

Attachment: Test Case

Comment 2

[Graham Yardley]

Attachment: Image of test case

Comment 3

[Boris Zbarsky [:bzbarsky]]

All the paragraphs have the same padding here (linux trunk build 2003-02-17-08).

Comment 4

[Graham Yardley]

[e-mail] said
> All the paragraphs have the same padding here (linux trunk build 2003-02-17-08).

I installed the 2003-02-22 nightly build my Redhat Linux 8.0
The bug was there as well.  Although the initial rendering is correct, if you
change the browser width after this, the padding will be incorrect.  Try opening
and closing the side panel.  

Comment 5

[Graham Yardley]

Tested in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 
Bug still exists.  

Comment 6

[Mike Cowperthwaite]

Confirming, couldn't find a dupe.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401

Comment 7

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

This is probably due to the resize reflow optimization in the block code (which
I think is basically bogus, for a number of reasons, since it doesn't do a deep
check of descendants, and which I'm tempted to remove).

Comment 8

[Jens Jäger]

Confirming with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5)
Gecko/20030925

Comment 9

[Greg K.]

Attachment: Simpler testcase

Comment 10

[Greg K.]

Encountered a similar, if not identical, problem using FF-Win/20050202.
Attaching another testcase and including a possibly more precise summary.

Possible duplicate: Bug 263537.

Doesn't depend on Quirks/Standards. Works fine in IE 6 and Opera 7.54.

Comment 11

[Martijn Wargers (dead)]

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

Comment 12

[Greg K.]

Also reproduced using Camino 0.8.2, so setting Hardware=All.

Comment 13

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

bug 263537 had a regression window

Comment 14

[Boris Zbarsky [:bzbarsky]]

That regression window was becase of the "focusing link triggers reflow" steps
to reproduce.  The range given is just the outline landing.

The "simpler testcase" given in this bug is broken with builds going back a long
ways.

Comment 15

[Raphael Schweikert]

There is a real live example of this bug on any page one the newly redesigned
http://www.sunrise.ch/-site (except the home page).
Note the footer, "Allgemeine Geschäftsbedingungen | Datenschutz | © TDC
Switzerland AG". It should always be aligned with the main content. The footer
has a padding-left of 19%, the same value as the navigation has for its width.
Now if you resize the browser window, the footer text gets out of sync with the
main content. An erratic window resize (sometimes) or a reload of the page
(without resize) makes the two elements align again.

Comment 16

[Raphael Schweikert]

Attachment: testcase derived from http://www.sunrise.ch/

I found this bug when I wanted to file it so I created a testcase that is
derived from the sunrise-site. It perhaps explains the problem better than the
previous two (but is also a bit more bloated…)

Comment 17

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061208 Minefield/3.0a1 ID:2006120812 [cairo]

seems fixed by reflow branch landing

Comment 18

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

*** This bug has been marked as a duplicate of 30802 ***