Last Comment Bug 471015 - Fieldsets are truncated to one page when printed / print-previewed
: Fieldsets are truncated to one page when printed / print-previewed
Status: NEW
Please read comments #27 and #31 befo...
: dataloss, productwanted, regression, testcase
Product: Core
Classification: Components
Component: Printing: Output (show other bugs)
: 2.0 Branch
: All All
: -- normal with 47 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
https://llkurser.cbs.dk/?page=public/...
: 505747 508498 648384 655713 811379 1174090 (view as bug list)
Depends on:
Blocks: 521204 463350
  Show dependency treegraph
 
Reported: 2008-12-23 21:14 PST by Nikolaj Lisberg Hansen
Modified: 2016-08-17 15:36 PDT (History)
47 users (show)
mbeltzner: blocking1.9.2-
mbeltzner: wanted1.9.2+
dveditz: wanted1.9.0.x+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
wontfix
wontfix
fix-optional
affected
affected
fix-wanted
wanted


Attachments
testcase 1 (1.79 KB, text/html)
2009-09-15 03:05 PDT, alfred.king
no flags Details
printout of testcase 1 [broken] (41.29 KB, application/pdf)
2009-09-15 03:06 PDT, alfred.king
no flags Details
printout of testcase 1 on debian lenny [broken] (19.08 KB, application/pdf)
2009-10-16 13:12 PDT, Martin Walsh
no flags Details
testcase 2: fieldset with 150 lines (taller than a page) (1.57 KB, text/html)
2009-10-27 09:23 PDT, Daniel Holbert [:dholbert]
no flags Details
Like So? (1.60 KB, patch)
2010-08-06 22:12 PDT, Saint Wesonga
roc: feedback-
Details | Diff | Splinter Review
fieldSet print bug test (7.06 KB, text/html)
2011-05-12 22:17 PDT, chang
no flags Details

Description Nikolaj Lisberg Hansen 2008-12-23 21:14:41 PST
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; InfoPath.2)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; da; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5

In Firefox 3 print and print preview of page renders fieldsets incorrectly making one fieldset span an entire page. 

In Firefox 2 there is no problem 
(Mozilla/5.0 (Windows; U; Windows NT 5.1; da; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14)  

Reproducible: Always

Steps to Reproduce:
1. In Firefox 3 go to the specified URL
2. Under the menu File select Print preview 
3. Scroll down to the second page of the print preview
Actual Results:  
Some fieldset boxes are rendered incorrectly

Expected Results:  
Fieldset boxes are rendered correctly like in Firefox 2 or IE
Comment 1 William White 2009-03-15 12:30:16 PDT
I am also seeing this problem with printing fieldsets.
Comment 2 Dan Smorey Jr. 2009-03-26 08:40:22 PDT
Same here with Firefox 3.0.7 on Mac OS X Leopard.  Have a page with a fieldset.  Even though there is practically no text "before" the fieldset.  When I print preview the fieldset always gets thrown to the top of the next page.

Nothing I put in the fieldset style will remedy this.

Just to confirm it's not something in my code, this same page with no changes, prints fine in Safari.
Comment 3 Peer Lalk 2009-08-24 09:07:53 PDT
Hello,

we have the same Problem with our new Portal.
My investigation so far:

1.5.0.10
 - When using a large fieldset the first page (with a header) will allways be wraped before the fieldset. Thereafter the fieldset is shown correct with all content (of course splitted into several pages)

2.0.0.12
 - Correct wrapping, no "empty" page at start, all content contained in the print

3.0.11
 - Same bahavior as with 1.5.0.10: page-break before the fieldset, then correct printout

3.5 - Very Big Problem !!
 - First of all again the page-break before the fieldset. But - the content is not correct. As soon as the first page of the fildset reaches the limit of the paper all successive content will not be printed or shown in the print-preview. The following fieldset is shown again, but will have the same problem when beeing to large for one page.
This bug results in a lost of content. The only way to get all content printed is to copy it to a textfile - or replace the fildset with a div.

3.6 - same problem as with 3.5 !

All versions run under Win-XP with latest SP.

To reproduce the Problem simply place a h1-header followed by a fieldset with enough text to fill up 2 DIN-A4-pages.

Since we use fieldsets due to accessibility reasons this is a big problem for our portal.
Maybe there could be a fix included within the next patches - as it allready worked fine with 2.0.0.12.
Comment 4 Justin Dolske [:Dolske] 2009-09-08 15:06:21 PDT
Seems to WFM on trunk with OS X, but moving to the right component for a further look.
Comment 5 Daniel Holbert [:dholbert] 2009-09-08 15:10:56 PDT
URL looks OK to me in Print Preview on Linux.

Could someone who sees the problem do one (or ideally both) of the following:
 - Attach a testcase that demonstrates the problem for you
 - Attach a screenshot of Print Preview that shows the broken behavior
  (or a print-to-PDF/PS printout, with a note about which page in the printout is broken)

Thanks in advance!
Comment 6 alfred.king 2009-09-15 03:05:15 PDT
Created attachment 400725 [details]
testcase 1
Comment 7 alfred.king 2009-09-15 03:06:24 PDT
Created attachment 400726 [details]
printout of testcase 1 [broken]
Comment 8 Charles Gutjahr 2009-09-29 01:16:24 PDT
I can confirm that this problem also occurs in the latest Mac build:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

The HTML example attached above prints exactly like that attached PDF - ie there is a pagebreak before the fieldset, and the fieldset is limited to one page and  cuts off extra content.
Comment 9 Martin Walsh 2009-10-16 13:10:30 PDT
Same here with the Linux build. 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Comment 10 Martin Walsh 2009-10-16 13:12:33 PDT
Created attachment 406757 [details]
printout of testcase 1 on  debian lenny [broken]
Comment 11 Bohdan Ganický 2009-10-27 08:51:20 PDT
You can test it here: http://jsbin.com/ocase/
Comment 12 Daniel Holbert [:dholbert] 2009-10-27 09:23:41 PDT
Created attachment 408610 [details]
testcase 2: fieldset with 150 lines (taller than a page)

Ok, I do see this bug using the posted testcase and the URL from comment 11.  In those examples, we've got a long fieldset (taller than a page height) that's truncated to 1 page long.

Here's a reduced testcase with numbered lines and no whitespace in the body, for cleaner frametree-dumps.

CONFIRMED AFFECTED BY BUG:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091027 Minefield/3.7a1pre

CONFIRMED UNAFFECTED BY BUG:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.18) Gecko/20081029 Firefox/2.0.0.18
Comment 13 Daniel Holbert [:dholbert] 2009-10-27 09:33:11 PDT
Also confirmed to be affected, using both attached testcases:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.16pre) Gecko/2009102704 GranParadiso/3.0.16pre

If someone could track down the first nightly build where this first broke (where the fieldset first started being truncated), that would be awesome. I've confirmed that breakage was somewhere between the Firefox 2.0.x branch and the Firefox 3.0.18 release.
Comment 14 Daniel Holbert [:dholbert] 2009-10-27 09:34:15 PDT
(In reply to comment #13)
> Firefox 3.0.18 release.
(er sorry, I meant "3.0.16", not that it matters much -- I expect that this became broken well before 3.0 was even a beta)
Comment 15 Daniel Holbert [:dholbert] 2009-10-27 09:45:00 PDT
*** Bug 505747 has been marked as a duplicate of this bug. ***
Comment 16 Daniel Holbert [:dholbert] 2009-10-27 09:48:13 PDT
Ha, looks like this may be a more recent regression than I'd thought. Off of a whim from looking at duplicate Bug 505747, I tested a 3.0.10 build, and that one is not broken.  So this has regressed on the 3.0.x branch in the time since 3.0.10 was released.  (Today's 3.0.16pre nightly is broken, but 3.0.10 isn't)
CONFIRMED UNAFFECTED BY BUG:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10
Comment 17 Daniel Holbert [:dholbert] 2009-10-27 10:01:29 PDT
*** Bug 508498 has been marked as a duplicate of this bug. ***
Comment 18 Daniel Holbert [:dholbert] 2009-10-27 10:27:31 PDT
(In reply to comment #13)
> If someone could track down the first nightly build where this first broke
> (where the fieldset first started being truncated), that would be awesome.

Tracked this down myself, on 1.9.0 branch, since the regression range looked to be pretty small.
WORKS:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.12pre) Gecko/2009062404 GranParadiso/3.0.12pre
BROKEN:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.12pre) Gecko/2009062504 GranParadiso/3.0.12pre
Comment 20 Daniel Holbert [:dholbert] 2009-10-27 10:37:53 PDT
The regression range on 1.9.1 matches bug 463350's checkin on that branch, too:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090522 Shiretoko/3.5pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090523 Shiretoko/3.5pre
Comment 21 Daniel Veditz [:dveditz] 2009-10-30 11:48:54 PDT
There are two bugs described here, see the timeline in comment 3. The bug was orginally filed against 3.0.5, about behavior that apparently regressed from 2.0 back to the incorrect 1.5 behavior (we fixed something in 1.8.1.x and forgot to land on trunk?).

Then a worse dataloss bug was introduced in 3.5, which eventually also landed in 3.0.12. I believe this patch is only fixing the latter problem, which is fine, but I don't want to lose track of the original formatting bug. If this patch doesn't fix that can we open a separate bug on the original problem?
Comment 22 Daniel Veditz [:dveditz] 2009-10-30 11:50:53 PDT
Looks like we need this dataloss fix on 1.9.2 also
Comment 23 Samuel Sidler (old account; do not CC) 2009-11-04 15:48:14 PST
dholbert: Can you work on this? If not, any recommendations? Our code freeze is set for November 10 at 11:59pm PDT.
Comment 24 Daniel Holbert [:dholbert] 2009-11-04 16:29:58 PST
I could possibly work on it, though roc might be a better choice, since he wrote bug 463350's patch and he has a better idea for the security implications/decisions behind that bug.

Based on bug 463350 comment 17, it sounds like our (currently-disabled) frameset-breaking code is pretty broken, and a safe fixup would require some non-trivial rewriting, which could be scary to land on branches (and could potentially open us up to bugs like bug 463350 again).  If we fix this and want to backport the fix to the 1.9.0.x branch, I think we'd need more than a few days of trunk-baking first.  So, I don't think this could make the 11/10 code-freeze cutoff for the next 1.9.0.x release...
Comment 25 Samuel Sidler (old account; do not CC) 2009-11-04 16:39:39 PST
Fair enough. Moving out blocking. We can discuss if we should fix this or not on 1.9.0 and 1.9.1 later.
Comment 26 Mike Beltzner [:beltzner, not reading bugmail] 2009-11-12 08:33:58 PST
Same decision for 1.9.2 as in comment 25; would take a patch, won't block the release.
Comment 27 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2010-01-26 11:20:38 PST
In bug 463350 I disabled fieldset splitting because the existing code was completely broken; it would sometimes produce the right visual results, but it could also crash in possibly exploitable ways. Fixing that would require more or less a complete rewrite of the fieldset code. Frame-splitting code tends to be very fragile and a great source of security bugs. Do we really want to land that rewrite on stable branches?
Comment 28 Daniel Holbert [:dholbert] 2010-01-26 11:50:30 PST
Unassigning for now -- I think Sam had just assigned it to me since I tracked down the regression, and per comment 24 & comment 27, this probably shouldn't be blocking anyway.

dveditz, can you confirm blocking vs. non-blocking on this?
Comment 29 Steve Crozier 2010-07-22 07:14:10 PDT
Can confirm that this is still a problem in 3.6.7. Both issues, page break before fieldset and truncation of fieldset larger than one page, are in evidence.
Comment 30 Saint Wesonga 2010-08-06 22:12:35 PDT
Created attachment 463760 [details] [diff] [review]
Like So?

Bug 463350 comment 17 explains why we disabled vertical breaking for fieldsets. Couldn't we just do smth similar to what we are doing for images?
Comment 31 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2010-08-07 03:33:10 PDT
No. This is going to lead to splitting of fieldset frames, which the fieldset code is not set up to handle.
Comment 32 Matt Giacomazzo 2011-03-01 09:55:15 PST
Still a problem in 3.6.13 Fieldsets should be allowed to be broken because I have plenty of cases where they exceed a page worth of content.
Comment 33 Matt Giacomazzo 2011-03-01 09:57:43 PST
(In reply to comment #31)
> No. This is going to lead to splitting of fieldset frames, which the fieldset
> code is not set up to handle.

This is not a proper response. This is causing a bug which makes many forms unusable when printed. Why take bug reports when you have no intention of changing the code to solve the issues?
Comment 34 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-03-01 12:04:50 PST
Because this patch is not the right change.
Comment 35 Daniel Holbert [:dholbert] 2011-04-07 20:21:12 PDT
*** Bug 648384 has been marked as a duplicate of this bug. ***
Comment 36 Cyril Chaboisseau 2011-05-12 06:43:35 PDT
All the bugs that has the word "fieldset" in the summary are duplicate of this one (see #508498, #191308, #471015, #505747, #655713)

This problem exists since January 2003 (most probably way before).
cf. bug 191308 (a test case is included)

The biggest problem is that some website are using this tag (fieldset) and when one user wants to print a confirmation page for an airplane ticket for instance, if Firefox doesn't allow the whole ticket to be printed, then the user will leave the browser with a bad feeling. Then, it is very difficult to have those users back.

This bug must be corrected once and for all (I recall that the bug was corrected in Nov. 2006 with version 1.5.0.7, so there was clearly a regression afterwards!)
Comment 37 chang 2011-05-12 22:13:53 PDT
Fieldsets are truncated to one page when printed / print-previewed 
Please try it by Attachments  fieldSetPrint.html
Comment 38 chang 2011-05-12 22:17:16 PDT
Created attachment 532122 [details]
fieldSet print bug test
Comment 39 Daniel Holbert [:dholbert] 2011-05-12 22:25:49 PDT
(In reply to comment #37)
> Fieldsets are truncated to one page when printed / print-previewed 

Yes, that's known. That's what this bug is filed on. :)

(In reply to comment #36)
> All the bugs that has the word "fieldset" in the summary are duplicate of
> this one (see #508498, #191308, #471015, #505747, #655713)

That's partly right. One of those is this bug, two others are already marked as duplicates, one other (655713) needs marking as a duplicate. (doing that now) 

But the remaining one, bug 191308, is from long before this was introduced, and it was correctly resolved as WORKSFORME until you recently reopened it. :)

> This problem exists since January 2003 (most probably way before).

No - this specific bug was caused by a checkin in late 2009 (see comment 18).  There may well have been other issues with fieldsets before then, but this bug can't cover all of those things.
Comment 40 Daniel Holbert [:dholbert] 2011-05-12 22:30:03 PDT
*** Bug 655713 has been marked as a duplicate of this bug. ***
Comment 41 OMA 2011-05-13 13:40:19 PDT
Still having this problem, even if this bug was filed back in December, 2008 :-(

Another example URL, so you can check:
http://www.classic-clocks.co.uk/options.asp?clockID=1&Requestor=gallery

That page contains a very long fieldset, which gets truncated.
As you can see in the above link, when printing:

1. The first page only has the title and a few paragraphs of text, then almost all of the page is blank because the fieldset doesn't fit in the first page, so it gets moved to the second page. It shouldn't do that! It should be printed just below the text, as shown in the browser!

2. The fieldset, even starting in a fresh new page, still doesn't fit in a single page, but its rendering doesn't continue in the third page. It just gets cut!

3. In the third page we get the remaining elements of the page (a div block with more text), but not the remaining content inside the fieldset, which just gets cut in the second page.

I hope some resources can be allocated to fix these very long running printing issues once and for all.
Comment 42 Daniel Holbert [:dholbert] 2011-05-13 14:03:11 PDT
(In reply to comment #41)
> Another example URL, so you can check:
> http://www.classic-clocks.co.uk/options.asp?clockID=1&Requestor=gallery

Thanks -- we've already got reduced testcases here (e.g. attachment 408610 [details]) so new URLs that also hit this bug don't add any new information.

> Still having this problem, even if this bug was filed back in December, 2008

See Comment 27 and Comment 31 for what's wrong here. Basically, the fieldset code is broken and needs a rewrite, which is probably a nontrivial task.
Comment 43 nemo 2011-10-11 07:55:54 PDT
Ran into this myself recently with our web pages:
http://m8y.org/tmp/testcase219.xhtml  iframe
http://m8y.org/tmp/testcase221.xhtml  paragraph

Right now, the only workaround really is to encourage users to use the Print Friendly Version button which loads the page into a popup and as well as setting the print style to normal for their viewing, also now strips fieldsets.
Comment 44 [:Aleksej] 2012-11-20 03:42:28 PST
*** Bug 811379 has been marked as a duplicate of this bug. ***
Comment 45 Adam DiCarlo 2013-04-03 15:52:02 PDT
Wow, a co-worker just ran into this. Any plans on finally fixing this bug? Working around it is a real pain and makes for a pretty bad time for web developers.
Comment 46 Andreas 2013-07-05 07:57:46 PDT
I work for a German finance IT company. Once every half a year or so, the customers of our banks call for support because of this bug.
We recommend using chrome or even Internet Explorer in this case.

If this is the way, Mozilla wants to handle this problem, maybe this bug should be declared as "wont fix".
Otherwise a fixing date would be very kind.

I know, that there might be more important things to do, but c'mon guys, Christmas this year, this bug is going to be 5 years old!?!
Comment 47 Pieter van Vliet 2013-10-31 19:26:52 PDT
Sorry folks, I have been waiting now for 3 1/2 years for this bug to finally get fixed. From my view it appears that more and more time is spent on adding eye-candy rather than fixing real bugs.

What do I have to do to give this bug a higher ranking so it finally gets the much needed attention?
Comment 48 tohafi 2014-04-11 02:13:10 PDT
Did someone fix this? If so you get a cookie!

We had the same problem with one of our customers sites for years now. But today, suddenly, our hack-around does more harm than good and if we remove it the print seems fine now...

FF 28.0
Comment 49 Cyril Chaboisseau 2014-04-11 06:53:28 PDT
well, I don't intend to be nasty but this bug is open for way too long (I've open the same myself in 2003 with bug 191308) and nobody seems to care to correct it -> this is *MORE* than 10 years!

the main problem is that is really refrains people (and sometimes companies) from using it when they stumble on this kind of bug for which they cannot do anything about it except switching to another browser

in the long run, it really gives Mozilla a bad name and maybe some top manager should be more worried about nailing this kind of bug instead of the version number craziness (18 versions in 2 years span)

PS : please, don't get me wrong: I'm a big fan of Mozilla and still using it daily on both my work/home computers as well as my mobile. But sometimes I don't have arguments anymore in my workplace when the colleagues give me this kind of long standing issues that never get fixed
Comment 50 nemo 2014-04-11 09:26:45 PDT
@ comment #48 - I retested in Nightly over here, and http://m8y.org/tmp/testcase219.xhtml still screws up printing until you click "remove fieldsets"
Comment 51 Loic 2015-06-12 09:09:24 PDT
*** Bug 1174090 has been marked as a duplicate of this bug. ***
Comment 52 Garrett W. 2016-04-04 10:04:15 PDT
I, too, can confirm that this bug is still present and would like it fixed.
Comment 53 roxana.leitan@softvision.ro 2016-05-10 04:16:51 PDT
20160502172042 Mozilla/5.0 (Windows NT 10.0; rv:46.0) Gecko/20100101 Firefox/46.0
20160509040557 Mozilla/5.0 (Windows NT 10.0; rv:49.0) Gecko/20100101 Firefox/49.0 

I have tested your issue on latest FF release (v. 46.0), latest Nightly build 49.0 and managed to reproduce it.
Comment 54 Gérard Talbot 2016-07-25 22:11:37 PDT
Semi-reduced self-explanatory test:

http://www.gtalbot.org/BugzillaSection/Bug471015-fieldset-truncated-print.html

Make sure you choose paper size: US letter (215,9mm wide by 279,4mm tall) and orientation:
Portrait when you try the test.

Firefox 47 buildID=20160606114208 and Firefox 50.0a1 buildID=20160711113740 fail this test.

Chrome 53.0.2785.21 and Opera 12.16 (Presto engine) pass this test.

* * * * * * *

Can anyone using IE11 or Edge 13.10586 (or even Edge 14.14352 if you have Windows 10 Pro) please tell me their result when print-previewing that test or when printing that test? *_Thank you!_*

* * * * * * *

It is possible to create a furthermore reduced test but then it would not be self-explanatory and not best for inclusion into CSS2.1 test suite.

- - - - - - -

"
If you agree the bug should be fixed, vote for it.
"
Bugzilla Etiquette
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Has everyone who want this bug to be fixed voted for this bug?
Comment 55 David Bolter [:davidb] 2016-08-17 12:46:58 PDT
Mike any ideas for this bug?
Comment 56 Mike Conley (:mconley) - (Needinfo me!) 2016-08-17 12:50:58 PDT
(In reply to David Bolter [:davidb] from comment #55)
> Mike any ideas for this bug?

I'm afraid that this bug seems to involve fieldset splitting, which (I believe) falls under Layout and is not exactly my area of expertise. Probably best to ask someone under Layout instead.

Note You need to log in before you can comment on or make changes to this bug.