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.
Status: UNCONFIRMED → NEW
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.
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
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)
When will this fix land?
It's already landed; sorry, I forgot to close out the bug.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.