User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081027 SeaMonkey/2.0a2pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081027 SeaMonkey/2.0a2pre When I hit the print key and print a page that has graphics, not all of the graphics show up. Some will print, some will show up as black squares. If I'm printing a page that is just text there is no problem (frex http://www.korval.com/saltation/ch01web.html prints with no problem). PDF pages print with no problem. But other pages fubar. Reproducible: Always Steps to Reproduce: A.1. Go to a webpage with graphics. frex http://heraldry.meridies.org/regalia.php 2. Hit print. B.1. Go to a webpage with PDF. frex http://heraldry.meridies.org/art/KingsChampion.pdf 2. Hit print. C.1. Go to a webpage with text only. frex http://www.korval.com/saltation/ch01web.html 2. Hit print. Actual Results: A. Text prints with no problems - graphics are hit & miss. B. Text prints with no problems, graphics print with no problems. C. Text prints with no problems. Expected Results: All pages should have printed accurately. I was using a Brother MFC-685CW. I checked to make sure that it was printing accurately on Evile-IE to ensure that it was not a software or hardware bug on the printer resulting in the use of about a quarter ream of paper. I tried printing on various different urls to see if it could have been a factor involving the code of the pages where I was attempting to print. Printing fubared everywhere. As a result, since this is a MAJOR factor in my work, I'm going to have to go down to the earlier version of Seamonkey for the time being because of fubar, fubar, and fubar since I absolutely refuse to use EvileIE or Virus Express no matter what anyone I talk to at any support network may say (and I make a point of telling them so).
(In reply to comment #0) > Steps to Reproduce: > A.1. Go to a webpage with graphics. frex > http://heraldry.meridies.org/regalia.php > 2. Hit print. > [...snip...] > A. Text prints with no problems - graphics are hit & miss. Confirmed with yesterday's nightly mozilla-central build, using the URL quoted above. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081027 Minefield/3.1b2pre Here are some experiments: Action images present? ------ --------------- a) Print-preview URL Yes b) Print URL to printer NO c) Print URL to PS file NO d) Print URL to PDF file Yes e) Print google.com to PS file Yes At the broken URL, I'm checking for the badge images on page 2. On Google, I'm checking for the Google logo image. The physical printer I'm using in experiment "b" is a Canon ImageRunner 4570.
Created attachment 345109 [details] URL printed to PS (note the missing badge images on page 2) (In reply to comment #1) > Action images present? > c) Print URL to PS file NO Here's the PS file generated from this experiment. Correct output would have an image above each chunk of blue link-text on the second page. (This PS file is missing those images)
Created attachment 345111 [details] testcase 1 Here's a reduced testcase.... It's literally just <img src="the GIF image I just attached"> This seems to be an issue with only *certain* classes of GIF images, I guess, since Google prints just fine, and it uses a GIF logo.
This bug is a regression with respect to Firefox 2 -- I just tried printing to PS and to my physical printer using Firefox 126.96.36.199/Linux, and both printouts had the image.
This is now WORKSFORME both on trunk and on the 1.9.1 branch. I also re-tested the build mentioned in comment 1, to confirm that it was still broken. To sum up: BROKEN: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081027 Minefield/3.1b2pre WORKING: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090106 Shiretoko/3.1b3pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090106 Minefield/3.2a1pre --> Resolving as WORKSFORME and clearing blocking-request.
I don't think it's worth the time checking for a regression range.
Yeah, sorry -- I forgot to clear "regressionrange-wanted" when closing this bug (and a few others that you've just caught -- thanks for cleaning up after me. :))