1106301 - Printing web-page only prints first page

Status: RESOLVED INVALID

(Core :: Printing: Output, defect)

Description

[NoOp]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30
Build ID: 20141017122933

Steps to reproduce:

Printing the following web page:

<http://www.familystylewithchefjeff.com/#!recipes/ckwa>



Actual results:


Only the first page is printed.




Expected results:

All 5 pages (using US Letter Portrait) should be printed. 

Tested with:
User agent: Mozilla/5.0 (Windows NT 6.3; rv:33.0) Gecko/20100101
Firefox/33.0 SeaMonkey/2.30
and
User agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101
Firefox/33.0 SeaMonkey/2.30
and
Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
and
Mozilla/5.0 (Windows NT 6.3; rv:33.0) Gecko/20100101 Firefox/33.0

Also tested using clean default 'test' profiles - no addons etc.

Printing the same page with Google Chromium and Opera results in
correctly printing of all 5 pages.

Comment 1

[therube]

Your URL is wrong.
Looks like it should be: http://www.familystylewithchefjeff.com/#!recipes/ckwa

(& in case that blows up, maybe this will work?)
> http://www.familystylewithchefjeff.com/#!recipes/ckwa

Anyhow, FF does the same, so if nothing else should be moved to Core (or somewhere else)?

Though I would think there are numerous existing similar print related bugs, so maybe look for DUPs first?

Comment 2

[NoOp]

The URL is correct and works just fine. I looked at possible duplicates prior to submitting this bug report.

Comment 3

[David E. Ross]

As this problem also afflicts non-Gecko browsers, this is not a SeaMonkey (or Core) bug.  Not only does the cited Web page contain 10 HTML5 errors and 8 CSS errors, but also the page's developer admitted that it was intended only for viewing with Google's Chrome.

Comment 4

[NoOp]

(In reply to David E. Ross from comment #3)
> As this problem also afflicts non-Gecko browsers, this is not a SeaMonkey
> (or Core) bug.  Not only does the cited Web page contain 10 HTML5 errors and

Perhaps you missed: "Printing the same page with Google Chromium and Opera results in
correctly printing of all 5 pages." Last time I looked, Chromium and Opera are Webkit based browsers. 

I've tested & printed all 5 pages US Letter portrait with:
Google Chromium 39.0 (linux)
Google Chrome 39.0 (Windows)
GNOME Epiphany 3.10.3
Opera 26.0 (linux and Windows)
Opera 12.16 (linux)

I'll be happy to upload PDF's from each if requested. 

> 8 CSS errors, but also the page's developer admitted that it was intended
> only for viewing with Google's Chrome.

The page developer stated: "Unfortunately we have a very small web budget so the website was developed on WIX so SeaMonkey v2.26.1 isn’t optimal for the WIX platform. We suggest Chrome to view the website." Please file *your own* Tech Evangelism bug if you wish.

I've reset the Product to 'Core' as this bug affects both SeaMonkey and Firefox.

Comment 5

[David E. Ross]

I hope the following helps to diagnose this problem.  These two items are from the mozilla.support.seamonkey newsgroup thread with subject "Printing - SeaMoney only prints first page".  

Per Ed Mullen (NNTP-Posting-Date: Tue, 02 Dec 2014 12:32:41 -0600):  

IE11 shows a print preview of 16 pages pretty much totally borked in layout.  Safari (Windows) says 10 pages but the text is gibberish.  Opera 16 doesn't seem to have print preview so I printed the first of 5 pages.  Text is total gibberish.  

Ant reported (NNTP-Posting-Date: Tue, 02 Dec 2014 10:57:20 -0600) that he received the following message from the owner of the problematic Web site:  

Date: Tue, 2 Dec 2014 08:53:11 -0800
From: Family Style with Chef Jeff <[e-mail]>
To: Ant...
Subject: Re: Web site problems.
X-Mailer: Apple Mail (2.1878.6)

Hello Ant,

Thank you for bringing this to our attention. What recipe would you like to print? We would be happy to send you a PDF version. Unfortunately we have a very small web budget so the website was developed on WIX so SeaMonkey v2.26.1 isn’t optimal for the WIX platform. We suggest Chrome to view the website. 

Thank you very much.

Best,
Family Style with Chef Jeff
www.familystylewithchefjeff.com
@FamilyStyleCook

Comment 6

[NoOp]

Ed should update to Opera 26. What have you tested with so far?

Comment 7

[NoOp]

Attachment: FamilyStyleRecipesOpera26Windows.pdf

Comment 8

[NoOp]

Attachment: FamilyStyleRecipesChromeWindows.pdf

Comment 9

[NoOp]

Attachment: FamilyStyleRecipesChromium.pdf

Comment 10

[NoOp]

Attachment: FamilyStyleRecipes_Epiphany.pdf

Comment 11

[NoOp]

Attachment: FamilyStyleRecipes_Opera26linux.pdf

Comment 12

[Mats Palmgren (inactive)]

A small testcase that demonstrates the bug in Firefox, but works in other UAs, would be
much appreciated.
https://developer.mozilla.org/en-US/docs/Mozilla/QA/Reducing_testcases

Comment 13

[NoOp]

(In reply to Mats Palmgren (:mats) from comment #12)
> A small testcase that demonstrates the bug in Firefox, but works in other
> UAs, would be
> much appreciated.
> https://developer.mozilla.org/en-US/docs/Mozilla/QA/Reducing_testcases

I've gotten to step 3 and can reproduce locally - I do not have enough knowledge about HTML or CSS to proceed further.

Comment 14

[NoOp]

Correction: I thought that I had all of the code locally (used wget), but disconnecting from the internet and attempting to load the code locally resultes in a blank webpage. Sorry, I cannot verify that I can reproduce locally.

Comment 15

[George Birbilis]

On Windows 10 with latest Firefox I also have this issue when trying to print long pages from 
http://amiconferences.org/2015

try printing the Program page for example (navigate from the side menu)

I found out that the problem is with IFRAME. The outer site hosts the inner site in an IFRAME (have done it using an IFRAME because later on the site will be moved permanently from its current IFRAME location for archiving at the location of the outer frame)

if you right click the Program link on the menu there and select to open in new window, you'll see the URL the IFRAME is showing resolves (currently) to http://daissy.eap.gr/AmI2015/program.php which does print preview (and print of couse) all pages ok (not just 1 as it does if you try to print the program when using the http://amiconferences.org/2015 link and click Program)

Comment 16

[George Birbilis]

sorry, the URLs I mention above don't work anymore for testing this bug, since we moved the site to its final place, not using IFRAME anymore, but could easily replicate using the descriptions I guess

Comment 17

[Mats Palmgren (inactive)]

There seems to be no working URLs, nor any reduced testcase the reproduces the problem.
Feel free to reopen the bug when there is one.  (Preferably a small testcase
uploaded to this bug report.)

Comment 18

[Daniel Holbert [:dholbert]]

Based on comment 15, I'm assuming a reduced testcase would be something like this:
(1)
data:text/html,<iframe%20src="http://daissy.eap.gr/AmI2015/program.php"%20style="height:98%;width:98%">

(2)
data:text/html,<iframe%20src="http://daissy.eap.gr/AmI2015/program.php"%20style="height:6000px;width:98%">

These indeed do not print or print-preview the way you might expect.

We only print one page for (1) because we paginate the outer document (the thing hosting the <iframe>), not scrollable things inside of it.

We only print one page for (2) because we don't support splitting tall <iframe> elements across pages. That is something we could conceivably fix -- we support doing this for images, for example.

Comment 19

[Daniel Holbert [:dholbert]]

I spun off bug 1250348 for my scenario labeled (2) in comment 18.

And I think we can't really fix my scenario (1); I only mentioned it for illustration purposes. (It's pretty much impossible to avoid truncated content, when there are nested scrollable areas, as is the case in (1).)

Comment 20

[George Birbilis]

here's the original IFRAME code (was hosted at http://ami-conferences.org/2015, but not anymore - now that has the site itself and the daissy.eap.gr/AmI2015/... one will be removed in the near future [stale copy]):

<html>

<head>

<title>AmI 2015 - European Conference on Ambient Intelligence</title>
<link rel="shortcut icon" type="image/ico" href='favicon.ico' />

<style type="text/css">
body
{
  margin:0;
  padding:0;
  overflow-y:hidden;
}

iframe 
{
  width:100%;
  height:100%;
  border:0;
  margin:0;
  padding:0;
}
</style>

</head>

<body>
  <iframe src="http://daissy.eap.gr/AmI2015">
    <a href="http://daissy.eap.gr/Ami2015">AmI 2015 - European Conference on Ambient Intelligence</a>
  </iframe>
</body>

</html>

Comment 21

[George Birbilis]

Note that a user of the browser doesn't and shouldn't care of the internal details of how a webpage has been implemented. The user should have a WYSIWYG experience regarding printing (or WYSIWYP - what you see is what you print - if you prefer).

Moreover the rule of least surprise shouldn't be broken - e.g. when they get "correct" printing in other browsers, it is normal to treat this strange printing behavior as a bug (they don't get what they were expecting as natural)

In my opinion both situations should be fixable. Pagination should happen at a later stage in the pipeline, first step should be to layout at a virtual page of infinite length, then break up in more pages and do the final render. Or could check out how other browsers do this, esp. any opensource ones

Comment 22

[Daniel Holbert [:dholbert]]

Yeah, comment 21 sounds like my example (1) from comment 18. The iframe's "height:100%" resolves against the height of the page, so you get exactly one page of content.  And we might even paint a scrollbar, but you can't scroll on a printed page. :)

Chrome does the exact same thing as we do on comment 20's example, BTW -- it truncates it to one page.  Do you know of any browser that prints comment 20 correctly?

(In reply to George Birbilis from comment #21)
> In my opinion both situations should be fixable. Pagination should happen at
> a later stage in the pipeline, first step should be to layout at a virtual
> page of infinite length, then break up in more pages and do the final
> render.

That is not quite how it works in Gecko -- that algorithm results in things like lines of text being split down the middle, so we do something more complicated.

Even with the simplified pipeline you describe, though, iframes and other scrollable elements are going to be impossible to print in general. Your testcase happens to be something where you can imagine how it *might* print nicely -- but if your iframe had e.g. "height: 100px" instead of "height:100%", then I'm curious how you would expect its contents to print.

Comment 23

[Daniel Holbert [:dholbert]]

Attachment: testcase 1, from comment 20 (er, doesn't work b/c bugzilla blocks iframe as 'mixed active content')

Comment 24

[Daniel Holbert [:dholbert]]

Attachment: (helper file for testcase 1)

Comment 25

[Daniel Holbert [:dholbert]]

Attachment: testcase 1, from comment 20

Comment 26

[George Birbilis]

as I wrote above, the browser user expect to see in print what they see on the screen, just paginated (if they had a printer that can print a roll of paper they'd expect no pagination for example)

they sure don't expect to just get one page

if I remember well I had tried with IE11 and probably with Edge too on Windows 10 and it was printing as expected

I guess what they do is they expand all content that is scrollable before printing (unless a print stylesheet defines otherwise). Probably the default print stylesheet of those browsers does the trick

what I mean is if I have a textarea in a page, probably even WYSIWYG isn't the best result, since after you print the textarea you can't scroll it anymore. More natural would be if the textarea is rendered for printing using enough size to host its content without a scrollbar. So in that case the outer IFRAME would see how much size its inner content needs to render and it would itself take that size (at least in height when printing portrait [for landscape probably would do this for width]) for the printing

Comment 27

[George Birbilis]

> Even with the simplified pipeline you describe, though, iframes and other scrollable elements are
> going to be impossible to print in general

see also my last reply - such content should be expanded to size their content without showing a scrollbar (probably via the default print stylesheet - if page author define other print stylesheet that overrides that behaviour, it's their choice)

if you see some sites that generate a "printable" version for their pages, they take care to expand all content so that there are no inner scrollable content. The browser should be clever enough to do the same I guess

Comment 28

[Daniel Holbert [:dholbert]]

Attachment: testcase 2, just to demonstrate that expanding scrollable areas is not clearly optimal

(In reply to George Birbilis from comment #27)
> see also my last reply - such content should be expanded to size their
> content without showing a scrollbar (probably via the default print
> stylesheet - if page author define other print stylesheet that overrides
> that behaviour, it's their choice)

In some cases, this might be appropriate. In many cases, it is not.  See this dummy blogpost I just whipped up as an example -- the post is short, and includes an extremely-long, mostly-unimportant, scrollable area. A user printing the post *might* want this scrollable area to be printed -- but they probably do not.

Moreover, we can't just ignore author-specified heights and explode scrollable things as you suggest, because the author might position something just after the scrollable thing (maybe with an exact position, using absolute positioning). And if we explode the scrollable thing to the height of its contents, we'd stomp on top of that next piece of content.

So, there's no magic bullet here; and any attempt at a magic bullet to fix one use-case would potentially break other use-cases.  So we do something simple.

Note also that there is spec text about this -- the CSS Working Group (which defines how content should render on the web) has a fragmentation spec which says:
> Some content is not fragmentable, for example
> [...] scrollable elements [...]. Such content
> is considered monolithic: it contains no
> possible break points.
https://www.w3.org/TR/css3-break/

If such an element is explicitly tall (as is the case with my example (2)), the spec says that browsers can render it to a tall, sliced-up buffer:
> the UA may also fragment the contents of monolithic elements
> by slicing the element’s graphical representation
...but that is not the case with your example, where we have an iframe which only as tall as a page. (height:100%)

Comment 29

[George Birbilis]

I guess you could argue the same way against a strategy of expanding just the first outer element that contains scrollable content (not related to whether scrollbar is visible or not)

question is why can't the user have a mental model of a infinitely long print page where they get the same content they get on the screen by scrolling down? How could they achieve it if layout for print isn't first done on such a virtual device and pagination done afterwards on the resulting content?

most probably the safest way to do this is to cover some edge cases by detecting them and deviating from the existing behaviour. Wonder though what IE does and if it is documented anywhere (+ if they do it via a default print stylesheet or special logic in their printing code)

Comment 30

[Daniel Holbert [:dholbert]]

(In reply to George Birbilis from comment #29)
> question is why can't the user have a mental model of a infinitely long
> print page where they get the same content they get on the screen by
> scrolling down?

That is pretty much exactly the right mental model.  The tricky thing with your example is that there are nested scrollable things (and the outer scrollable thing doesn't actually have any scrollable overflow).

Whenever there are nested scrollable things, your infinitely-long-page model breaks down -- or rather, it still works, but the inner scrollable thing doesn't get the ability to be scrolled on the printed page.

> Wonder though what
> IE does and if it is documented anywhere (+ if they do it via a default
> print stylesheet or special logic in their printing code)

I actually just tested IE and Edge, and they agree with Firefox & Chrome on your testcase (as hosted on bugzilla, as attachment 8722263 [details]) -- they only print 1 page.

So, it looks like all browsers are in agreement here.

Comment 31

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #30)
> So, it looks like all browsers are in agreement here.

(Note that browsers were originally *not* in agreement on the original URLs here, at 
familystylewithchefjeff.com , as shown by the attached PDFs. But, that domain's printing issue isn't reproducible anymore in Firefox, per comment 17 [and per my own testing today] -- either because the site was fixed or because Firefox was fixed. And that was likely a different underlying issue from George's iframe issue, anyway.)

Comment 32

[George Birbilis]

strange, I'm pretty sure I had it tested then with different browsers - can't find any screenshots in my dropbox from that date I had posted about the issue, unless I had dealt with it earlier and posted later on when I found this bug report

could be that:
- I changed that .html file (don't see any important change in version control though)
- or browsers behave differently when the .html with the IFRAME is opened locally and when running from a web server
- or IE11 on Win10 has changed heavior compared to IE11/Win8 that I probably had back then on my laptop (I've seen e.g. some SVG fixes in IE11/Win10 [some D3 example now works fine when it didn't in IE11/Win8], probably because of some shared SVG engine with Edge or something). Will see if I can find sometime to try with earlier MS browsers https://dev.windows.com/en-us/microsoft-edge/tools/vms/windows/

Comment 33

[Daniel Holbert [:dholbert]]

I'll undo the "INCOMPLETE" resolution from comment 17, since we have a working testcase now (at least for the later issue that George reported).

But, I'm going to re-close as INVALID, since our behavior matches what every other browser seems to do, and what the spec calls for, and it's unclear that we could robustly do anything different for fixed-height nested scrollable things without breaking other content, as discussed in my comments above.

Comment 34

[NoOp]

(In reply to Mats Palmgren (:mats) from comment #17)
> There seems to be no working URLs, nor any reduced testcase the reproduces
> the problem.
> Feel free to reopen the bug when there is one.  (Preferably a small testcase
> uploaded to this bug report.)

The original URL that I reported this bug with works just fine. 
http://www.familystylewithchefjeff.com/#!recipes/ckwa

(In reply to Daniel Holbert [:dholbert] from comment #33)
> I'll undo the "INCOMPLETE" resolution from comment 17, since we have a
> working testcase now (at least for the later issue that George reported).
> 
> But, I'm going to re-close as INVALID, since our behavior matches what every
> other browser seems to do, and what the spec calls for, and it's unclear
> that we could robustly do anything different for fixed-height nested
> scrollable things without breaking other content, as discussed in my
> comments above.

Please also note that it is NOT the case that the behavior matches every other browser; Chrome, Opera, and MS Edge print all 5. Would you like me to again post the most recent print PDF's from those browsers? Please reset the bug back to Verified.

Comment 35

[Daniel Holbert [:dholbert]]

(In reply to NoOp from comment #34)
> (In reply to Mats Palmgren (:mats) from comment #17)
> > There seems to be no working URLs, nor any reduced testcase the reproduces
> > the problem.
> > Feel free to reopen the bug when there is one.  (Preferably a small testcase
> > uploaded to this bug report.)
> 
> The original URL that I reported this bug with works just fine. 
> http://www.familystylewithchefjeff.com/#!recipes/ckwa

Thanks for clarifying -- in a fresh profile, I can confirm that I get 1 useful page & 3 blank pages with that URL. (I'd tested before in my normal browsing profile with NoScript and gotten nice working content; I didn't test further, but probably should have.)

> > But, I'm going to re-close as INVALID, since our behavior matches what every
> > other browser seems to do
> 
> Please also note that it is NOT the case that the behavior matches every
> other browser;

This comment was about George's testcase (and tangentially about your testcase as well, in that I thought it worked correctly in Firefox).

Focusing back on the familystylewithchefjeff.com page (which is completely unrelated to the iframe-dependent issues with the page that George brought up here): it looks like each piece of content there is absolutely positioned, e.g.:
<div style="top: 3089px; left: 678px; width: 350px; position: absolute;" class="s6" id="WRchTxt1-prc" data-reactid=".0.$SITE_ROOT.$desktop_siteRoot.$PAGES_CONTAINER.1.1.$SITE_PAGES.$ckwa.1.$WRchTxt1-prc"><h5 style="line-height: 1.2em; " class="font_5"><u>Almond Dream Milkshake</u></h5>
</div>
...with "top" getting progressively larger as you go down the page.

That means this is a duplicate of bug 546559, I think.

Comment 36

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #35)
> That means this is a duplicate of bug 546559, I think.

Or rather, bug 267029 (which is subtly different from bug 546559).

Comment 37

[NoOp]

Thanks & that looks to be the correct bug report. However bug 267029 is a 12 year old bug report... so I reckon that this is not likely to be fixed any time soon.