Closed
Bug 415285
Opened 17 years ago
Closed 17 years ago
FireFox 3.0 on windows : printing of plugin contents is over-printed
Categories
(Core :: Printing: Output, defect, P2)
Tracking
()
RESOLVED
FIXED
People
(Reporter: phil.race, Assigned: vlad)
Details
Attachments
(1 file)
(deleted),
patch
|
pavlov
:
review+
|
Details | Diff | Splinter Review |
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.
Updated•17 years ago
|
Status: UNCONFIRMED → NEW
Component: General → Printing
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → printing
Assignee | ||
Comment 1•17 years ago
|
||
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+
Assignee | ||
Comment 2•17 years ago
|
||
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.
Updated•17 years ago
|
Priority: -- → P2
Assignee | ||
Updated•17 years ago
|
Assignee: nobody → vladimir
Assignee | ||
Comment 3•17 years ago
|
||
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)
Updated•17 years ago
|
Attachment #302719 -
Flags: review?(pavlov) → review+
Comment 4•17 years ago
|
||
When will this fix land?
Assignee | ||
Comment 5•17 years ago
|
||
It's already landed; sorry, I forgot to close out the bug.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•