Closed Bug 578128 Opened 14 years ago Closed 14 years ago

Firefox 3.6.x fails to print beyond page 1 when two nested <div> use style float: left

Categories

(Core :: Layout: Floats, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 550866

People

(Reporter: J.S.Peatfield, Unassigned)

References

()

Details

(Keywords: regression)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.4) Gecko/20100623 (ff36 in DAMTP) Red Hat/3.6-8.el5 Firefox/3.6.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.4) Gecko/20100623 (ff36 in DAMTP) Red Hat/3.6-8.el5 Firefox/3.6.4

Some of our internal web pages show this because our house style happens to use a number of nested <div> values I've constructed a fairly simple test page with most of the junk stripped out which shows the problem.

I'm unclear whether having these nested div's with float: left is breaking some rule but earlier versions of firefox, and other web browsers don't seem to show this effect.

It does not affect firefox 3.5.x so this seems to have been introduced since 3.5 branch was split from trunk.

A quick binary chop through the nightly releases shows it isn't present for the ftp://ftp.mozilla.org/pub/firefox/nightly/2009/07/2009-07-13-03-mozilla-central download but is for ftp://ftp.mozilla.org/pub/firefox/nightly/2009/07/2009-07-14-03-mozilla-central version.  Those versions of firefox (mainline) identify themselves (via about:buildconfig) as:

last working version:  http://hg.mozilla.org/mozilla-central/rev/b9012a18d2c6
First non-working:   http://hg.mozilla.org/mozilla-central/rev/9b4dd06e1c9d

I've started looking at:

  http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b9012a18d2c6&tochange=9b4dd06e1c9d

but it seems that a lot of changes were checked in between those points in time, so tracking down the problem might take me much longer that someone who is familiar with the code.


Reproducible: Always

Steps to Reproduce:
1.  Point a web browser at http://www.damtp.cam.ac.uk/user/jp107/testprin.html
2.  Go to File -> Print-Preview - observe that only one page is shown
3.  Try with http://www.damtp.cam.ac.uk/user/jp107/testprin2.html and see that
    two pages are shown.
Actual Results:  
Only one page is shown in print-preview (or printed) 

Expected Results:  
That document should be two pages.

The two testprin documents differ just by whether we have overriden the float: left for print media for one of the two div's - doing either seems to make things work:

$ diff -bu testprin{,2}.html
--- testprin.html       2010-07-12 19:27:05.000000000 +0100
+++ testprin2.html      2010-07-12 19:58:47.000000000 +0100
@@ -17,7 +17,7 @@
 /*  float: none;*/
 }
 div#damtptestdiv2 {
-/*  float: none;*/
+  float: none;
 }
 </style>
 
I'd say that there is an easy workround but since the styling is often imposed by higher authorities overriding it may not always be possible.  Anyone who did testing before firefox 3.6 won't have noticed this behaviour.

BTW I tested that the problem still exists in the latest nightly from nightlies (identifies itself as http://hg.mozilla.org/releases/mozilla-1.9.2/rev/c4bde810db3f) and also still isn't present in the nightlies of the 1.9.1 branch.  I've not yet had time to check if this is fixed in Trunk.
Version: unspecified → 3.6 Branch
Some co-workers have tested with firefox 3.6.6 on Win32 and 3.6.4 on MacOSX and they see similar (bad) behaviour so it isn't just Linux.  I'm about to try to change this to all/all for arch/os.

Of the patches between the two dates only:

 http://hg.mozilla.org/mozilla-central/rev/0149bbd87df5

seems to mention the float / layout but that may be a red herring.
OS: Linux → All
Hardware: x86 → All
similar to/ dup of bug 522604?

or Bug 549659
Component: General → Layout: Floats
Keywords: regression
Product: Firefox → Core
QA Contact: general → layout.floats
Version: 3.6 Branch → Trunk
Having been told by a co-worker that the problem is apparently fixed in ff 4beta I've been through a large number of mc builds to see where the fix happened, and found that it was done  between (2009-08-31) http://hg.mozilla.org/mozilla-central/rev/d87974838fa9 and (2009-09-01) http://hg.mozilla.org/mozilla-central/rev/e3e594837a30

Looking at the bz the most obvious changes refer to (https://bugzilla.mozilla.org/show_bug.cgi?id=492627) that mentions another bug that this is almost certainly a DUP of:  https://bugzilla.mozilla.org/show_bug.cgi?id=550866

Perhaps it would be best to add my (fairly simple) testcase to that bug.  I'm not sure what the proper etiquette is for this hence I'm seeking guidance from a mozilla expert.
Should be retested after bug 563584 lands.
Depends on: 563584
From the description https://bugzilla.mozilla.org/show_bug.cgi?id=522604 seems to be a different problem (in that it existed before the problem with nested div's started).  At least imho...

https://bugzilla.mozilla.org/show_bug.cgi?id=549659 may well be the same problem, certainly it has a pair of nested div's in the test case given there.

Is https://bugzilla.mozilla.org/show_bug.cgi?id=563584 targetting the 1.9.2 branch?  (I'm just interested since it looks like quite a major piece of work).
bug 563584 is not aimed at the 1.9.2 branch.  (At least some of what it fixes is regressions since 1.9.2.)
(In reply to comment #3)
> Perhaps it would be best to add my (fairly simple) testcase to that bug

Yes, please use the "Add an attachment" link
It would actually be best to add the testcase to this bug report.
Flags: in-testsuite?
As requested.  If either of the commented out float:none lines for the media=print are uncommented then I get two pages as expected.
Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100712 Minefield/4.0b2pre

attachment 457055 [details] works on trunk (fails with 1.9.2.6)
NEW or WFM or dup of bug 549659?
status1.9.2: --- → ?
Dup of bug 550866, based on description of bug and matching regression range & fix range.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: