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. ***

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.

putting this into the 1.0.1 bucket

*** Bug 129617 has been marked as a duplicate of this bug. ***

updating summary

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.

batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

is this strictly a print preview problem, or are we not printing plugins/applets at all?

this is print preview only

*** Bug 223889 has been marked as a duplicate of this bug. ***

*** Bug 227347 has been marked as a duplicate of this bug. ***

*** 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. ***

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.

Mostly too late for 1.9.1 but bringing on the radar for 1.9.2.

With the work on bug 191046 this will hopefully be fixed on OS X.

Not blocking 1.9.2 on this.

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.

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

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.

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)!