Open
Bug 133465
Opened 23 years ago
Updated 2 years ago
[Layout] Printing should wait for images to load (images not already in cache don't print)
Categories
(Core :: Print Preview, defect, P2)
Tracking
()
NEW
Future
People
(Reporter: john.p.baker, Unassigned, Mentored)
References
()
Details
Attachments
(1 obsolete file)
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
confirming...I also see the problem...using 3/26 build.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 2•23 years ago
|
||
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•23 years ago
|
||
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?
Reporter | ||
Comment 4•23 years ago
|
||
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.
Reporter | ||
Comment 5•23 years ago
|
||
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•23 years ago
|
||
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.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → Future
Updated•23 years ago
|
Summary: generated content (image) not shown in print/print preview unless in memory cache → Images not loaded in galley mode, aren't loaded during printing.
Comment 7•22 years ago
|
||
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.
Depends on: 113173
Updated•15 years ago
|
Assignee: rods → nobody
Status: ASSIGNED → NEW
QA Contact: sujay → printing
Reporter | ||
Comment 9•15 years ago
|
||
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
Updated•7 years ago
|
Priority: P1 → P2
Summary: Images not loaded in galley mode, aren't loaded during printing. → [Layout] Printing should wait for images to load (images not already in cache don't print)
Comment 12•7 years ago
|
||
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.
Attachment #77620 -
Attachment is obsolete: true
Updated•7 years ago
|
Comment 13•7 years ago
|
||
(...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•7 years ago
|
||
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
Updated•7 years ago
|
Mentor: jwatt
Updated•2 years ago
|
Severity: normal → S3
Comment 15•2 years ago
|
||
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.
Flags: needinfo?(jwatt)
Comment 16•2 years ago
|
||
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.
Flags: needinfo?(jwatt)
You need to log in
before you can comment on or make changes to this bug.
Description
•