471015 - Fieldsets are truncated to one page when printed / print-previewed

Status: RESOLVED FIXED

(Core :: Printing: Output, defect, P3)

Description

[Nikolaj Lisberg Hansen]

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]

I am also seeing this problem with printing fieldsets.

Comment 2

[Dan Smorey Jr.]

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]

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]]

Seems to WFM on trunk with OS X, but moving to the right component for a further look.

Comment 5

[Daniel Holbert [:dholbert]]

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]

Attachment: testcase 1

Comment 7

[alfred.king]

Attachment: printout of testcase 1 [broken]

Comment 8

[Charles Gutjahr]

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]

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]

Attachment: printout of testcase 1 on debian lenny [broken]

Comment 11

[Bohdan Ganický]

You can test it here: http://jsbin.com/ocase/

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: 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]]

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]]

(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

[Daniel Holbert [:dholbert]]

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 18

[Daniel Holbert [:dholbert]]

(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

[Daniel Holbert [:dholbert]]

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

[Daniel Holbert [:dholbert]]

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]]

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]]

Looks like we need this dataloss fix on 1.9.2 also

Comment 23

[Samuel Sidler (old account; do not CC)]

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]]

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)]

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]]

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) (email my personal email if necessary)]

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]]

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]

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]

Attachment: 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) (email my personal email if necessary)]

No. This is going to lead to splitting of fieldset frames, which the fieldset code is not set up to handle.

Comment 32

[u407859]

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

[u407859]

(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) (email my personal email if necessary)]

Because this patch is not the right change.

Comment 36

[Cyril Chaboisseau]

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]

Fieldsets are truncated to one page when printed / print-previewed 
Please try it by Attachments  fieldSetPrint.html

Comment 38

[chang]

Attachment: fieldSet print bug test

Comment 39

[Daniel Holbert [:dholbert]]

(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 41

[OMA]

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]]

(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]

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 45

[Adam DiCarlo]

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]

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]

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]

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]

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]

@ 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

[Garrett W.]

I, too, can confirm that this bug is still present and would like it fixed.

Comment 53

[roxleitan]

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]

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] (NeedInfo me for attention)]

Mike any ideas for this bug?

Comment 56

[Mike Conley (:mconley) (:⚙️)]

(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.

Comment 57

[nemo]

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

[Andrew Overholt [:overholt]]

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

[jon]

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.

Comment 60

[nemo]

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)

Comment 61

[shawnc]

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

[Charlie Morris]

Would love to see this fixed. Is there a way to fix this in CSS? Overriding some default behaviors in a print style sheet?

Comment 63

[Mats Palmgren (inactive)]

I can take a look at this...

Comment 64

[Mats Palmgren (inactive)]

Attachment: Bug 471015 - [css-break] Implement <fieldset> fragmentation. r=TYLin

Comment 65

[Mats Palmgren (inactive)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=f394cd12c5e4fe03bed31a739e48f6068d0e49ad

Comment 66

[Mats Palmgren (inactive)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=781c643a06e685e611c5840d7e0b9e0256e3e12d

Comment 67

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0186165ee1d8
[css-break] Implement <fieldset> fragmentation.  r=TYLin

Comment 68

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/20435 for changes under testing/web-platform/tests

Comment 69

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Comment 70

[Cristian Brindusan [:cbrindusan]]

Backed out changeset 0186165ee1d8 (Bug 471015) for reftest failures at box-shadow/611574-1.html.
https://hg.mozilla.org/integration/autoland/rev/d639574e500e0cfea377b3d294a1998c69ed5cff

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception&revision=0186165ee1d84f56362ba16bbda4eefa1d47fd60&selectedJob=278053629

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=278053629&repo=autoland&lineNumber=23870

Comment 71

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 72

[Mats Palmgren (inactive)]

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

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2684fdcd6fbf
[css-break] Implement <fieldset> fragmentation.  r=TYLin

Comment 74

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Comment 76

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/2684fdcd6fbf

Comment 77

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 78

[Gérard Talbot]

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?

Comment 79

[Mats Palmgren (inactive)]

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

[Gérard Talbot]

Done: bug 1602107