133465 - [Layout] Printing should wait for images to load (images not already in cache don't print)

Status: NEW

(Core :: Print Preview, defect, P2)

Description

[John P Baker]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+)
Gecko/20020318
BuildID:    2002031803



Reproducible: Always
Steps to Reproduce:
1.Go to URL http://www.bris.ac.uk/is/selfhelp/documentation/pwd-i1/pwd-i1.htm
2.Print Preview (or print page 1)
3.Close print preview
4.Print Preview (or print page 1)
5.Close print preview
6.Clear memory cache
7.Print Preview (or print page 1)

Actual Results:  The image (ISbw120a) doesn't appear at top left after step 2 or
step 7

Expected Results:  Image should appear as it does after step 4

Comment 1

[sujay]

confirming...I also see the problem...using 3/26 build.

Comment 2

[John P Baker]

This has a great number of similarities with layout/reflow bug 126072.
It could just depend on whether the image is available in time for the
(premature) last reflow/reframe.

Comment 3

[rods (gone)]

I think clearing the cache could break a lot things in printing or print
preview. We rely on images being in the cache to print. I think there is a
general bug about printing not working if the cach is turned off.

Is there a way to produce this without clearing the cache?

Comment 4

[John P Baker]

Just do steps 1 and 2.

The image doesn't show at step 2 when you first preview the page, which suggests
that it isn't available at this stage. If you close this print preview and preview again, the
image will now show. I was guessing that it appeared in the cache after the preview was
laid out.
Clearing the cache at step 6 isn't necessary to produce the problem, it just reactivates it.

Comment 5

[John P Baker]

Attachment: testcase for this bug

I have had time to create a testcase for this problem.

1. Start fresh browser (or clear memory cache)
2. go to http://www.cse.bris.ac.uk/~ccjpb/printpreview.html (see attachment)
3. print preview

The page first shows with a picture placeholder where the image should be, it
then gets filled with a squashed image.

4. close print preview
5. print preview

All is now fine.

(Win2K 2002040203)

Comment 6

[rods (gone)]

Bottom Line: If the image wasn't loaded in Galley, Printing or Print Preview
will not load it, this is a known issue. We made the assumption (good or bad)
that all images would be in the cache.

Comment 7

[Boris Zbarsky [:bzbarsky]]

The problem here is that printing just does a single reflow and then goes.  If
the image is first loaded when we enter printing mode, it has no time to load
before printing happens.  Fixing bug 113173 may fix this if we start storing
image requests in the style data; even so printing the page before onload fires
may not print the images correctly.

Comment 9

[John P Baker]

I was looking to see if bug 487667 affects the behaviour here but it seems that something else (image preload?) has already muddied the water; Whatever the reason a modified testcase (the original test image no longer exists) currently WFM.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a1pre) Gecko/20091211 Minefield/3.7a1pre ID:20091211044651

Comment 12

[Daniel Holbert [:dholbert]]

Comment on attachment 77620 [details]
testcase for this bug

The attached testcase is obsolete (because it references an externally-hosted image that is now "Not Found"). But the testcase from duplicate bug 848695 (attachment 8424961 [details]) still works as a testcase here, since it uses a bugzilla-hosted image.

Comment 13

[Daniel Holbert [:dholbert]]

(...though I actually can't reproduce with that attachment, even in a fresh profile, possibly because it downloads fast enough and we've shuffled tasks around such that we're more likely to "win" the race condition nowadays.  I assume if I were on a slow connection, I'd still be able to reproduce, but I'm not entirely sure.)

Comment 14

[Jonathan Watt [:jwatt]]

The last of the five patches for bug 468568 made it possible for the static clone doc that we create when printing to load font files (and made printing wait for the font files to load):

https://hg.mozilla.org/integration/mozilla-inbound/diff/84317c2f199c/content/base/src/nsDataDocumentContentPolicy.cpp

Fixing this bug may be as simple as relaxing the restrictions at:

https://dxr.mozilla.org/mozilla-central/rev/7b46ef2ae1412b15ed45e7d2367ca491344729f7/dom/base/nsDataDocumentContentPolicy.cpp#69

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:jwatt, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 16

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.