Reproduced with Camino 1.0b2. Unsure if this is a Core or Camino bug. Using the "Print..." menuitem, and then previewing as PDF, this extremely simple testcase fails: <html> <body> <p style="background-color:red">test</p> </body> </html> Basically the red background color is used for all of the page in the printed PDF.
This is a blocker for me printing my CV as PDF ;-) I have to use Safari (oh, the pain)!
Does this work in Firefox?
In 1.0rc1, I just get a white page, no red at all (anywhere). cl
Håkan, do you have "Print Background Colors" selected in the Camino pane of the print dialogue? It's unchecked by default.
Yes, with "Print background colors" on, this bug is reproduced. Without that checked, I get no colors at all.
More data: * this bug is fixed in firefox trunk * this bug is also fixed on Camino trunk! The bug still exists however in Camino 1.0rc1. Does anyone know what checkin fixed this? I think this should be considered for 1.0 if the fix wasn't risky. Bz: the bug experienced is while printing (to PDF in this case). If you use a background-color attribute, and you print with background colors on, that color will be used for all of the page - not just the element it is specified on. Does this sound like a familiar regression to you; any idea what checkins might have fixed this on trunk?
(In reply to comment #6) > Yes, with "Print background colors" on, this bug is reproduced. > > Without that checked, I get no colors at all. Isn't that a bug in its own right? Colours specified by the page should be there if "print background colors" is checked. cl
I guess the reasoning is that the "background-color" property, even when specified on an element, is a background color and therefore should not be shown when that checkbox is ticked off. However, personally I feel that body bgcolor represents the page's background color, and other background colors are just as any colors on the page...
Note that if you do a simple "regression range" search the right checkin is glaringly obvious in bonsai... *** This bug has been marked as a duplicate of 294836 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
Thanks, should've caught that! I think this bug is useful to keep open to track whether we intend to apply it to Camino 1.0 Do we have to get it into the 1.8-branch then, or what's the process? Nominating.. I'll let you guys proceed since I'm not very up to date with the process.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Unapproved branch changes to core (that aren't expected to be approved) aren't really 1.0 material. If you want it on the branch, you need to request it from the other bug but, since it's not a regression stability/security fix, I doubt they'll approve it. I'll let someone else minus, but I don't think this will/should be in 1.0.
no, not for 1.0. nominate the dupe for the 18branch. *** This bug has been marked as a duplicate of 294836 ***
Status: REOPENED → RESOLVED
Last Resolved: 13 years ago → 13 years ago
Flags: camino1.0? → camino1.0-
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.