Fieldsets are truncated to one page when printed / print-previewed
Categories
(Core :: Printing: Output, defect, P3)
Tracking
()
People
(Reporter: nlh, Assigned: MatsPalmgren_bugz)
References
(Blocks 2 open bugs, )
Details
(4 keywords, Whiteboard: Please read comments #27 and #31 before commenting [layout:print-triage:p1], [wptsync upstream][frag2020_v72])
Attachments
(6 files, 1 obsolete file)
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•15 years ago
|
||
I am also seeing this problem with printing fieldsets.
Comment 2•15 years ago
|
||
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.
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•15 years ago
|
||
Seems to WFM on trunk with OS X, but moving to the right component for a further look.
Updated•15 years ago
|
Comment 5•15 years ago
|
||
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•15 years ago
|
||
Comment 7•15 years ago
|
||
Comment 8•15 years ago
|
||
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•15 years ago
|
||
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•15 years ago
|
||
Comment 11•15 years ago
|
||
You can test it here: http://jsbin.com/ocase/
Comment 12•15 years ago
|
||
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•15 years ago
|
||
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•15 years ago
|
||
(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 16•15 years ago
|
||
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
Updated•15 years ago
|
Updated•15 years ago
|
Updated•15 years ago
|
Comment 18•15 years ago
|
||
(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 19•15 years ago
|
||
bonsai link for regression range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2009-06-24+03%3A30%3A00&maxdate=2009-06-25+04%3A30%3A00&cvsroot=%2Fcvsroot Looks like bug 463350 caused this.
Comment 20•15 years ago
|
||
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
Updated•15 years ago
|
Comment 21•15 years ago
|
||
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•15 years ago
|
||
Looks like we need this dataloss fix on 1.9.2 also
Comment 23•15 years ago
|
||
dholbert: Can you work on this? If not, any recommendations? Our code freeze is set for November 10 at 11:59pm PDT.
Comment 24•15 years ago
|
||
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•15 years ago
|
||
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•15 years ago
|
||
Same decision for 1.9.2 as in comment 25; would take a patch, won't block the release.
Updated•14 years ago
|
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•14 years ago
|
||
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?
Updated•14 years ago
|
Comment 29•14 years ago
|
||
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•14 years ago
|
||
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?
No. This is going to lead to splitting of fieldset frames, which the fieldset code is not set up to handle.
Comment 32•13 years ago
|
||
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•13 years ago
|
||
(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?
Because this patch is not the right change.
Comment 36•13 years ago
|
||
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•13 years ago
|
||
Fieldsets are truncated to one page when printed / print-previewed Please try it by Attachments fieldSetPrint.html
Comment 38•13 years ago
|
||
Comment 39•13 years ago
|
||
(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.
Updated•13 years ago
|
Comment 41•13 years ago
|
||
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•13 years ago
|
||
(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•13 years ago
|
||
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.
Updated•12 years ago
|
Comment 45•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
@ 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 52•8 years ago
|
||
I, too, can confirm that this bug is still present and would like it fixed.
Comment 53•8 years ago
|
||
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.
Updated•8 years ago
|
Comment 54•8 years ago
|
||
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?
Updated•8 years ago
|
Comment 55•8 years ago
|
||
Mike any ideas for this bug?
Comment 56•8 years ago
|
||
(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.
Updated•8 years ago
|
Updated•8 years ago
|
Comment 57•8 years ago
|
||
The most annoying thing about this bug for me personally is that fieldsets are a pretty useful way to render some separate html inside a page without messing up the parsing/css. So, my workaround, which is to yank it out of the fieldset and into a div for the print preview, has a decent chance of screwing up the page if some user screws up with an RTE. I've special-cased the workaround as Firefox-only, but still kinda bothersome, even w/ Firefox' increasingly small marketshare.
Comment 58•8 years ago
|
||
Given that I understand this is a not-insignificant amount of work and the time remaining in the upcoming cycles and the age of this thorny issue, I'm marking fix-optional for 50 and 51. Seeing this block bug 1302489 is a hopeful sign for the not-too-distant future (thanks, Jet!).
Comment 59•7 years ago
|
||
I think it's a bit ridiculous that a significant bug like this has still not been addressed 9 years later. Our website uses fieldsets to separate sections of our reports, and several sections become truncated when printing in Firefox. We are now advising all users to no longer use Firefox for our site.
Updated•7 years ago
|
Comment 60•7 years ago
|
||
Little reply to comment #59 - while I do sympathise with the annoyingness of this bug, first time I encountered it, it took like 10 minutes to make a fix for my generic print preview popup (it's a popup that sucks the parent page in and applies the print styling plus fixups - browsers always seem to need fixups) - just sucked the iframes into divs in the parent page - much like my testcase higher up in this bug. It's really not that hard. And, frankly, the "use another browser" approach just gets silly when it comes to printing - of all the browsers I've tested with our varied printed reports, IE was the friendliest - Chrome couldn't even do reliable page-break-after / page-break-before on a long table with sections. Slap a page-break-after *anywhere* inside a table was just bad times. Or even before it sometimes.. Had to guess at where a page would be and break up the table. Even then it took a lot of tweaking to avoid it screwing up and overlapping the thead. I guess you *could* design your report to only support one browser. For an internal app that's not crazy - but even here, while 90% of users use IE, still needed to support Chrome and Firefox. (Chrome being as noted the truly insane one)
Updated•7 years ago
|
Comment 61•5 years ago
|
||
Still an issue 11 years later with v67.0.2. For now, I'm using this workaround, but it's less than ideal.
<script type="text/javascript">
if (navigator.userAgent.toLowerCase().indexOf('firefox') > -1) {
$(window).bind("beforeprint", function () {
$("fieldset").each(
function () {
$(this).replaceWith($('<div class="fieldset">' + this.innerHTML + '</div>'));
}
);
});
$(window).bind("afterprint", function () {
$(".fieldset").each(
function () {
$(this).replaceWith($('<fieldset>' + this.innerHTML + '</fieldset>'));
}
);
});
}
</script>
Comment 62•5 years ago
|
||
Would love to see this fixed. Is there a way to fix this in CSS? Overriding some default behaviors in a print style sheet?
Updated•5 years ago
|
Assignee | ||
Comment 63•5 years ago
|
||
I can take a look at this...
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 64•5 years ago
|
||
Assignee | ||
Comment 65•5 years ago
|
||
Assignee | ||
Comment 66•5 years ago
|
||
Comment 67•5 years ago
|
||
Pushed by mpalmgren@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0186165ee1d8 [css-break] Implement <fieldset> fragmentation. r=TYLin
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/20435 for changes under testing/web-platform/tests
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Comment 70•5 years ago
|
||
Backed out changeset 0186165ee1d8 (Bug 471015) for reftest failures at box-shadow/611574-1.html.
https://hg.mozilla.org/integration/autoland/rev/d639574e500e0cfea377b3d294a1998c69ed5cff
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=278053629&repo=autoland&lineNumber=23870
Upstream PR was closed without merging
Assignee | ||
Comment 72•5 years ago
|
||
The test that failed (layout/reftests/box-shadow/611574-1.html) depends on <fieldset>
not being able to fragment.
I'll fix the test and reland...
Comment 73•5 years ago
|
||
Pushed by mpalmgren@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2684fdcd6fbf [css-break] Implement <fieldset> fragmentation. r=TYLin
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Comment 76•5 years ago
|
||
bugherder |
Upstream PR merged by moz-wptsync-bot
Updated•5 years ago
|
Comment 78•4 years ago
|
||
Mats,
Semi-reduced self-explanatory test:
http://www.gtalbot.org/BugzillaSection/Bug471015-fieldset-truncated-print.html
Make sure you choose paper size: A4 (210mm wide by 297mm tall) and orientation:
Portrait when you try the test. Paper size A4 is best since it is selectable and supported in both Firefox and Chrome.
With Firefox 73.0a1 buildID=20191206093947, I get 3 pages with "PASS" appearing in the 3rd page. With Chromium 78.0.3904.108, I get 2 pages with "PASS" appearing in the 2nd page. The difference is that Firefox generates a page break in the first page for unknown and unexpected reason. I would expect Firefox to start rendering the fieldset on the first page and not after a page break.
Should I create another bug report?
Assignee | ||
Comment 79•4 years ago
|
||
It passes for me if I remove one line of text from the <h3>
, but yeah it looks like there should already be room to start the fieldset on first page. Please file a new bug.
Comment 80•4 years ago
|
||
Done: bug 1602107
Updated•4 years ago
|
Updated•4 years ago
|
Description
•