1.79 KB, text/html
41.29 KB, application/pdf
19.08 KB, application/pdf
1.57 KB, text/html
1.60 KB, patch
|Details | Diff | Splinter Review|
7.06 KB, text/html
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:220.127.116.11) 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:18.104.22.168) Gecko/20080404 Firefox/22.214.171.124) 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
I am also seeing this problem with printing fieldsets.
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: 126.96.36.199 - 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) 188.8.131.52 - Correct wrapping, no "empty" page at start, all content contained in the print 3.0.11 - Same bahavior as with 184.108.40.206: 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 220.127.116.11.
Seems to WFM on trunk with OS X, but moving to the right component for a further look.
Component: General → General
Product: Firefox → Core
QA Contact: general → general
Component: General → Printing: Output
QA Contact: general → printing
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!
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:18.104.22.168) 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.
Same here with the Linux build. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20090824 Firefox/3.5.3
You can test it here: http://jsbin.com/ocase/
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:126.96.36.199) Gecko/20081029 Firefox/188.8.131.52
Also confirmed to be affected, using both attached testcases: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206pre) 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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Summary: Print and print preview of page with fieldsets renders incorrectly in Firefox 3 → Fieldsets are truncated to one page when printed / print-previewed
Version: unspecified → Trunk
(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)
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:220.127.116.11) Gecko/2009042315 Firefox/3.0.10
Attachment #400725 - Attachment description: testcase (fieldsetbugtest.pdf shows the false printing) → testcase 1
Attachment #400726 - Attachment description: fieldsetbugtest.pdf shows the false printing → printout of testcase 1 [broken]
Attachment #406757 - Attachment description: result of printing Alfred's testcase (debian lenny) → printout of testcase 1 on debian lenny [broken]
(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:18.104.22.168pre) Gecko/2009062404 GranParadiso/3.0.12pre BROKEN: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124pre) Gecko/2009062504 GranParadiso/3.0.12pre
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.
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
blocking1.9.1: --- → ?
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?
Looks like we need this dataloss fix on 1.9.2 also
dholbert: Can you work on this? If not, any recommendations? Our code freeze is set for November 10 at 11:59pm PDT.
Assignee: nobody → dholbert
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...
Fair enough. Moving out blocking. We can discuss if we should fix this or not on 1.9.0 and 1.9.1 later.
blocking1.9.1: .6+ → .7+
Flags: blocking126.96.36.199+ → blocking188.8.131.52+
Same decision for 1.9.2 as in comment 25; would take a patch, won't block the release.
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?
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?
Assignee: dholbert → nobody
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.
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?
Attachment #463760 - Flags: feedback?(roc)
No. This is going to lead to splitting of fieldset frames, which the fieldset code is not set up to handle.
Attachment #463760 - Flags: feedback?(roc) → feedback-
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.
(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.
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 184.108.40.206, so there was clearly a regression afterwards!)
Fieldsets are truncated to one page when printed / print-previewed Please try it by Attachments fieldSetPrint.html
(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.
Attachment #532122 - Attachment mime type: text/plain → text/html
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.
(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.
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.
Attachment #400726 - Attachment mime type: application/download → application/pdf
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.
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!?!
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?
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
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 #48 - I retested in Nightly over here, and http://m8y.org/tmp/testcase219.xhtml still screws up printing until you click "remove fieldsets"
I, too, can confirm that this bug is still present and would like it fixed.
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.
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?
3 years ago
Version: Trunk → 2.0 Branch
Mike any ideas for this bug?
(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.
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.
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!).
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.
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)
You need to log in before you can comment on or make changes to this bug.