Closed Bug 134002 Opened 18 years ago Closed 7 years ago

Content of plugins (flash, java applets) doesn't get rendered for printing or print preview

Categories

(Core :: Plug-ins, defect, P3)

defect

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: peterlubczynski-bugs, Unassigned)

References

()

Details

(Keywords: relnote, topembed-, Whiteboard: [PL2:P3])

Attachments

(1 file)

Bug 122048 fixed print preview such that plugins won't cause a crash or hang by
deactivating them altogether. This bug is about reactivating plugins in PP.

The plan is to create an offscreen that the plugin renders into once and then
just display that for PP. That solves widget reparenting issues, freezes
animations and events, plus simulates IE's behavior.
isn't bug 133994 covering the same issue?
*** Bug 133994 has been marked as a duplicate of this bug. ***
Attached patch temporary patchSplinter Review
May want to put this in until we get it all working, otherwise we may get a ton
of dups.
I don't like adding temporary info because:

The size of the plugin may vary and the text may get cropped
The background color may make the string unreadable anyway.
The string would need to be localized and I believe localization freeze is tomorrow

This should probably be relnoted.
Keywords: relnote
putting this into the 1.0.1 bucket
Priority: -- → P3
Target Milestone: --- → mozilla1.0.1
*** Bug 129617 has been marked as a duplicate of this bug. ***
updating summary
Summary: Plugins don't render in print preview → Plugins/applets don't render in print preview
There is quite a bit of work to be done for getting plugins to show up
*correctly* in print preview. Because the plugin API does not support it, we've
somehow got to "snap a picture" of the plugin and display that. Some of the work
may have to be done in gfx or the platform widget toolkits. Pushing out to
plugins 2.0 work.
Whiteboard: [PL2:P3]
Target Milestone: mozilla1.0.1 → mozilla1.2alpha
Target Milestone: mozilla1.2alpha → mozilla1.2beta
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
Target Milestone: mozilla1.2beta → mozilla1.3alpha
is this strictly a print preview problem, or are we not printing plugins/applets
at all?
Keywords: topembedtopembed-
this is print preview only
Blocks: grouper
Target Milestone: mozilla1.3alpha → Future
*** Bug 223889 has been marked as a duplicate of this bug. ***
*** Bug 227347 has been marked as a duplicate of this bug. ***
Blocks: 248936
*** Bug 261449 has been marked as a duplicate of this bug. ***
*** Bug 264239 has been marked as a duplicate of this bug. ***
*** Bug 324001 has been marked as a duplicate of this bug. ***
In bug 324001, which I've now duped to this one, I noted that print preview of PDF documents currently shows a blank page.  I presume that this is covered by this bug, unless a whole-page plugin is treated significantly differently from an embedded plugin.

In the case of a whole-page non-embedded PDF, is it reasonable for Moz to do a print-preview at all?  In bug 324001 I suggested that perhaps the Preview menu item should be disabled for PDF pages.

--Phil.
*** Bug 319630 has been marked as a duplicate of this bug. ***
*** Bug 329731 has been marked as a duplicate of this bug. ***
Duplicate of this bug: 248936
Eli, you happen to know what should be done here?
There is some obvious code in nsObjectFrame.cpp that should be removed, but that doesn't really seem to help.
Fixing this is basically unworkable until there is some capability to draw a plugin to an arbitrary surface.  Also, there's no point to rendering plugins in print preview until we can print them.  I'm sure there's a bug somewhere about printing plugins; I can't remember the number.
Well, printing seems to work for me. At least, I tried to print a flash file to a pdf printer driver and that seemed to work. Not sure about other plugins.
See my comment #17; in the case of PDF (and presumably other formats) printing is handled by the plugin itself (and works), but preview isn't.  So for full-page plugins I feel that print preview should be disabled in the UI.
(In reply to comment #23)
> Well, printing seems to work for me. At least, I tried to print a flash file to
> a pdf printer driver and that seemed to work. Not sure about other plugins.

Sorry, I wasn't really thinking... it does work for Flash (although not much else.)  The obvious fix is making the print preview case do the same thing as the print case, right?  I'm pretty sure that should work, at least in simple cases.  I might be forgetting something, though.  (See also Bug 317447.)

(In reply to comment #24)
> See my comment #17; in the case of PDF (and presumably other formats) printing
> is handled by the plugin itself (and works), but preview isn't.  So for
> full-page plugins I feel that print preview should be disabled in the UI.

Full-page plugins are a completely different codepath; please file another bug.
Thanks for the explanation, Eli!

(In reply to comment #25)
> Full-page plugins are a completely different codepath; please file another bug.

Well, that bug (bug 324001) was made a duplicate against this bug. So I've reopened that bug.

Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9-
Whiteboard: [PL2:P3] → [PL2:P3][wanted-1.9]
Flags: wanted1.9+
Whiteboard: [PL2:P3][wanted-1.9] → [PL2:P3]
Duplicate of this bug: 375062
Duplicate of this bug: 292644
Assignee: peterl-bugs → nobody
QA Contact: shrir → plugins
Duplicate of this bug: 457915
Duplicate of this bug: 240954
Flags: wanted1.9.1?
Summary: Plugins/applets don't render in print preview → Content of plugins (flash, java applets) doesn't get rendered for printing or print preview
Mostly too late for 1.9.1 but bringing on the radar for 1.9.2.
Flags: blocking1.9.2?
Duplicate of this bug: 491674
With the work on bug 191046 this will hopefully be fixed on OS X.
Depends on: 191046
Not blocking 1.9.2 on this.
Flags: blocking1.9.2? → blocking1.9.2-
Flags: wanted1.9.1?
My manifestation of the problem is both in the Print Preview and in the Print functions, involving what appears to be Flash content graphics that don't display in Firefox but display and print fine in IE.

There appears to be a patch shown above.  How do I apply that patch?  Any help appreciated!  (I'm not a programmer)
If you are not a programmer then you probably not in a position to compile the browser.  Unless you can compile it the patch won't help you.
Duplicate of this bug: 567151
Reproduceable on:
 Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0

*Note: Print preview for an inline pdf file displays a blank page.
Adobe Plugin Version: 10.0.1.434
Duplicate of this bug: 644076
Duplicate of this bug: 574674
Duplicate of this bug: 812804
Bug 838763 now covers disabling both the print and print-preview buttons for fullpage plugins. For in-content plugins I don't think we care about printing at this point.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
For those, who want to print pages with plugins content, just switch from Firefox to IE9/10, it allows you to print all you want.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #42)
> Bug 838763 now covers disabling both the print and print-preview buttons for
> fullpage plugins. For in-content plugins I don't think we care about
> printing at this point.

Why ever not?  This is pretty basic stuff, and other browsers seem to be able to handle it!

If you don't care about printing 'in-content plugins' then how comes you care about printing images - I'm not sure what the conceptual difference is from a user's point of view.

(I'm well aware of the implementation differences from a developer's point of view.)

Please reopen (and - more importantly - fix)!
You need to log in before you can comment on or make changes to this bug.