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:188.8.131.52) 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:184.108.40.206) Gecko/20080404 Firefox/220.127.116.11)
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
Some fieldset boxes are rendered incorrectly
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.
we have the same Problem with our new Portal.
My investigation so far:
- 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)
- Correct wrapping, no "empty" page at start, all content contained in the print
- Same bahavior as with 18.104.22.168: 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 22.214.171.124.
Seems to WFM on trunk with OS X, but moving to the right component for a further look.
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!
Created attachment 400725 [details]
Created attachment 400726 [details]
printout of testcase 1 [broken]
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:126.96.36.199) 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:188.8.131.52) Gecko/20090824 Firefox/3.5.3
Created attachment 406757 [details]
printout of testcase 1 on debian lenny [broken]
You can test it here: http://jsbin.com/ocase/
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:184.108.40.206) Gecko/20081029 Firefox/220.127.116.11
Also confirmed to be affected, using both attached testcases:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168pre) 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.
(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)
*** Bug 505747 has been marked as a duplicate of this bug. ***
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:22.214.171.124) Gecko/2009042315 Firefox/3.0.10
*** Bug 508498 has been marked as a duplicate of this bug. ***
(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.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199pre) Gecko/2009062404 GranParadiso/3.0.12pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52pre) Gecko/2009062504 GranParadiso/3.0.12pre
bonsai link for regression range:
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
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.
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.
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?
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.
Created attachment 463760 [details] [diff] [review]
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.
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.
*** Bug 648384 has been marked as a duplicate of this bug. ***
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
Created attachment 532122 [details]
fieldSet print bug test
(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.
*** Bug 655713 has been marked as a duplicate of this bug. ***
Still having this problem, even if this bug was filed back in December, 2008 :-(
Another example URL, so you can check:
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:
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:
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.
*** Bug 811379 has been marked as a duplicate of this bug. ***
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...
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"
*** Bug 1174090 has been marked as a duplicate of this bug. ***
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.