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

Status: RESOLVED FIXED

(Core :: Printing: Output, defect, P2)

Description

[Phil Race]

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.

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: 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.

Comment 4

[Kenneth Russell]

When will this fix land?

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

It's already landed; sorry, I forgot to close out the bug.