bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

FireFox 3.0 on windows : printing of plugin contents is over-printed




Printing: Output
10 years ago
10 years ago


(Reporter: Phil Race, Assigned: vlad)


Windows XP
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)



(1 attachment)



10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008020104 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008020104 Minefield/3.0b3pre

This is a follow-on to https://bugzilla.mozilla.org/show_bug.cgi?id=408623
to address the part of that bug which was overlooked in its fixing.

The bug concerns printing a web-page which contains Java applet content,
using the Java plugin. Java receives messages, and prints to the printer
DC supplied by firefox, and with that fix correctly informs the plugin
of the location it should print in device units.

The submission of the above bug did describe this as part of the problem,
but only the x/y conversion was fixed

Reproducible: Always

Steps to Reproduce:
Install a plugin and visit a web-page which uses it, and
print the webpage.
Actual Results:  
The plugin-contents are missing. I can tell the contents are
reaching the page, since if I adjust the destination I can force
the plugin-content to appear in the margins of the page but is
clipped at the edges inside the margins. ie exactly as if either
the area inside the margins is over-printed completely after printing the
plugin content, or as if that area is clipped.

Expected Results:  
The contents printed at its intended destination.
Component: General → Printing
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → printing
This is because plugins print straight to the DC, and we buffer printing so that we can do any necessary bitmap fallback at the end.  We may have to shove plugins off to a separate DC that we then composite in towards the end.
Flags: blocking1.9+
Idea I'll have to think about:

We add an api to the win32 printing surface to pass in natively-drawn rectangles; when we do the final render, we use that region to clip out the fallback rendering.  The object frame calls the rectangle-exclusion function for each plugin that gets printed.  Should work.


10 years ago
Priority: -- → P2
Assignee: nobody → vladimir
Created attachment 302719 [details] [diff] [review]
use native drawing code for plugin printing

Use gfxWindowsNativeDrawing for printing plugins on win32.

Note that if we used gfxWindowsNativeDrawing for normal painting of windowless plugins, we could get them working with foreignTransform.
Attachment #302719 - Flags: review?(pavlov)


10 years ago
Attachment #302719 - Flags: review?(pavlov) → review+

Comment 4

10 years ago
When will this fix land?
It's already landed; sorry, I forgot to close out the bug.
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.