Closed Bug 312415 Opened 19 years ago Closed 19 years ago

Selected images (from a selection of the document to print) are black

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9alpha1

People

(Reporter: windaria, Assigned: bzbarsky)

References

(
URL
)

Details

(Keywords: fixed1.8.1, regression, verified1.8.0.1)

Attachments

(1 file)

I think this is the right fix...
1.24 KB, patch
roc
: review+
roc
: superreview+
dveditz
: approval1.8.0.1+
dveditz
: approval1.8.1+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

While I can print the page, and it prints fine, any time I select a range of the
page to print, such as from the Game Reviews image that goes across the top of
the review down to the second to the last paragraph of the body of the review,
the images print as black images with diagnal lines over them. If I print the
doucment normally they look fine. This is true for this page as well as any
other page on which an image is selected.

I could find no other mention of this bug. I have a Canon i9100 and am using
Firefox Beta 2 for Windows 2000.

Reproducible: Always

Steps to Reproduce:
1. Select images and text to print
2. Go to file > Print and select Selection
3. Click OK

Actual Results:  
As specified in Details, the images do not print properly.

Expected Results:  
The images should have printed, they do not.

I am not entirely sure that I have the correct severity selected, however I
decided to go with Major because printing selections of web pages is a major
feature, at least as far as I am concerned, and thusly qualifies it as greater
than Normal.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051006
I have the same setup, same problem with Print range = Selection. I'm printing
to a Brother 1870N laser on ethernet. I noticed this problem a few days ago with
what seemed to be text in a table format. Today it is definitely true with
graphics at, e.g., http://firefox.dbltree.com/
I have the same problem.  I just updated from 1.0.7 to beta 2 of 1.5.  I have a
Canon LBP 1260 Laser Printer (LaserJet 4 Engine) and I print shipping labels
from the UPS site daily.  Since the update I have not been able to highligh the
label and print selection.  If I print the whole page the it prints fine, or if
i right click and choose view Image then I can print just the label portion, so
it seems to just be a problem whe there is a selection involved, and that
selection is a graphic.  If there is text and Graphic then the text comes out
ok, but the graphic is Solid black with horozontal grey lines thouh it.

The workaround for now is to do the Right Click - View Image then print from the
new window, and since I just want the label this will work for me.
As I said the other day, it is not only graphics. For example, view:

http://www.hrcp-web.org/P_releases.cfm

highlight some text and print it, and it is all black.

If graphic or "bad" text is highlighted, and (perhaps accidentally) you print
the whole page, the highlighted part still comes out black.
Not all tables print black when selected. E.g., tables on Bugzilla pages.

This looks like Bug 311726
Is is neccessary to show the selection at all?
If not, the removing of the selection prior to print may be a quick fix.
Both IE and Opera do not show the selection in print.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → printing
Component: General → Printing
Product: Firefox → Core
QA Contact: general
Version: unspecified → 1.8 Branch
Yes, definetely a regression from bug 306262.
Backing out the patch from that bug, makes this bug disappear in my debug build.
Blocks: 306262
Keywords: regression
*** Bug 316018 has been marked as a duplicate of this bug. ***
We used to not enable selection at all in a presshell without a docshell, but that seems pretty odd to me.  If printing can't handle selections, it should just turn them off and be done with it.
Attachment #204199 - Flags: superreview?(roc)
Attachment #204199 - Flags: review?(roc)
Attachment #204199 - Flags: superreview?(roc)
Attachment #204199 - Flags: superreview+
Attachment #204199 - Flags: review?(roc)
Attachment #204199 - Flags: review+
Assignee: printing → bzbarsky
OS: Windows 2000 → All
Hardware: PC → All
Target Milestone: --- → mozilla1.9alpha
Version: 1.8 Branch → Trunk
Fixed.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
*** Bug 318167 has been marked as a duplicate of this bug. ***
This fixes the problem on the 1.8 branch, too. Would be great to get this into 1.8.1, as there is no approval flag for that I am (ab)using the blocking flag.
Flags: blocking1.8.1?
(In reply to comment #12)
> This fixes the problem on the 1.8 branch, too. Would be great to get this into
> 1.8.1, as there is no approval flag for that I am (ab)using the blocking flag.
> 

Could that be because the next relase will be 1.8.0.1 and there IS an approval flag for that?
1.8.0.1 is a security and crash fix release, as I understand.  But maybe the plan's changed again; who knows.

If people want this on the 1.8 branch, they need to do a lot more testing than I've been able to do so far and then make the case for it to drivers.  I really don't have the time for either of those.
*** Bug 318339 has been marked as a duplicate of this bug. ***
(In reply to comment #14)
> 1.8.0.1 is a security and crash fix release, as I understand.  But maybe the
> plan's changed again; who knows.
> 
> If people want this on the 1.8 branch, they need to do a lot more testing than
> I've been able to do so far and then make the case for it to drivers.  I really
> don't have the time for either of those.
> 

Have a look to the Roadmap http://cbeard.typepad.com/.shared/image.html?/photos/uncategorized/releaseroadmapdraftv1_2.png
Gecko 1.8.1, will be released with Firefox 2.0.

I think such an essential bug should fixed before G1.9 which is F3.0!

How do you imagine testing for this Fix? Please describe it a little bit for me.

And is there any change to get this Fix into the comming F1.5 Builds?
I'm quite familiar with the roadmap.

Testing would involve testing all sorts of selection-related printing stuff.

1.5 has shipped, so there is no way this is getting fixed in 1.5.  In fact, the bug was filed after non-security-or-crash-issue freeze for 1.5...
Shouldn't we change "Status:" from RESOLVED, and "Resolution:" from FIXED?

This question may be naive (since I'm not a programmer), but with Firefox's automatic updating feature, why is there "no way this is getting fixed in 1.5"? When IE has a problem, MS doesn't wait for IE 7 to patch it.
(In reply to comment #18)
> Shouldn't we change "Status:" from RESOLVED, and "Resolution:" from FIXED?
> 
> This question may be naive (since I'm not a programmer), but with Firefox's
> automatic updating feature, why is there "no way this is getting fixed in 1.5"?
> When IE has a problem, MS doesn't wait for IE 7 to patch it.
> 

1.  The Resolved and FIXED status refer to the status of the bug in the current source code tree, not the sate of the latest released product.

2.  The "no way this is getting fixed in 1.5" meant it will not be (and obviously was not) in the 1.5 release version.  If it is subsequently patched via software update, that will change the version number to a 1.5.x.x version. So it will possibly be fixed via software update before version 2.0.
> why is there "no way this is getting fixed in 1.5"?

Apart from the impossibility of time travel, that's not an issue of "can't do it" as much as of "shouldn't do it".  Under-tested changes should not be made to the "stable" release tree.

> When IE has a problem, MS doesn't wait for IE 7 to patch it.

Depends on the problem, doesn't it?
bz, roc: What would be required before requesting approval1.8.0.1 ?
Testing.  If you've tested enough that you're sure this doesn't break anything, request approval.
NOT RESOLVED!

Try in trunk:
Select some text with images. Select File -> Print preview. Preview looks fine. Close preview. Try to select something in the page. You can not select anything in the page. You have to reload the page to do that.
Sorry! I'm ashamed, i was too fast.
The described problem exist also in 1.5
Still a chance to fix it too.
That has nothing to do with this bug.  Please file a bug on it, if there isn't one already.
*** Bug 319239 has been marked as a duplicate of this bug. ***
Could this patch potentially have fixed bug 319357? (not even sure if that one is still a problem in current trunk builds, though)
Yeah, it could have.   Certainly that exact stack can no longer arise...
So in that case, wouldn't it be wise to make this blocking 1.8.0.1, since bug 319357 is a topcrasher for 1.5 branch (see bug 319357, comment 6)?
Requesting blocking; can someone confirm that this really does fix bug 319357?  And has anyone done some serious testing of this patch?
Flags: blocking1.8.0.1?
I can't reproduce bug 319357, so I can't confirm.
Ria or Peter, can you see bug 319357, and can you see if it is fixed in the time the fix for this bug got checked into the tree?
(In reply to comment #31)
I have no printer :)

no printer here either
(In reply to comment #33)
> no printer here either
> 

There are many free print-to-pdf programs available on the web, which you could use to test this.
*** Bug 322425 has been marked as a duplicate of this bug. ***
This seems to have fixed bug 319357
Based on what?  See bug 319357 comment 11.
Boris, I've tested the correct builds now (2005-11-29 and 2005-11-30) and 2005-11-30 seems to have fixed the problem.
Comment on attachment 204199 [details] [diff] [review]
I think this is the right fix...

I think bz meant to request patch approval
Attachment #204199 - Flags: approval1.8.1?
Attachment #204199 - Flags: approval1.8.0.1?
Comment on attachment 204199 [details] [diff] [review]
I think this is the right fix...

a=dveditz
Attachment #204199 - Flags: approval1.8.1?
Attachment #204199 - Flags: approval1.8.1+
Attachment #204199 - Flags: approval1.8.0.1?
Attachment #204199 - Flags: approval1.8.0.1+
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1+
*** Committing to MOZILLA_1_8_BRANCH... 
/cvsroot/mozilla/layout/printing/nsPrintEngine.cpp,v  <--  nsPrintEngine.cpp
new revision: 1.97.4.2; previous revision: 1.97.4.1

*** Committing layout/printing/nsPrintEngine.cpp on MOZILLA_1_8_0_BRANCH... 
/cvsroot/mozilla/layout/printing/nsPrintEngine.cpp,v  <--  nsPrintEngine.cpp
new revision: 1.97.4.1.4.1; previous revision: 1.97.4.1
Keywords: fixed1.8.0.1, fixed1.8.1
verified fixed on the branch using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1. I tested using the URL cited and was able to print a selection of images and text fine.
Keywords: fixed1.8.0.1 → verified1.8.0.1
*** Bug 324811 has been marked as a duplicate of this bug. ***
*** Bug 320418 has been marked as a duplicate of this bug. ***
There is still a problem with printing selected TEXT. Choose any webpage with text taking more than one printed page. Select a range of text. The printing does not break the lines at the end of the page. The the top part of the letters in the bottom line will print on page 1, and the bottom part will print at the top of page 2.
That's not related to this bug at all.  Please file a separate bug if one is not filed yet.
*** Bug 321290 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: