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

RESOLVED WONTFIX

Status

()

Core
Plug-ins
P3
normal
RESOLVED WONTFIX
16 years ago
4 years ago

People

(Reporter: Peter Lubczynski, Unassigned)

Tracking

({relnote, topembed-})

Trunk
Future
relnote, topembed-
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 -
blocking1.9 -
wanted1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PL2:P3], URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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.

Comment 1

16 years ago
isn't bug 133994 covering the same issue?

Comment 2

16 years ago
*** Bug 133994 has been marked as a duplicate of this bug. ***

Comment 3

16 years ago
Created attachment 76591 [details] [diff] [review]
temporary patch

May want to put this in until we get it all working, otherwise we may get a ton
of dups.
(Reporter)

Comment 4

16 years ago
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

Comment 5

16 years ago
putting this into the 1.0.1 bucket
Priority: -- → P3
Target Milestone: --- → mozilla1.0.1
(Reporter)

Comment 6

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

Comment 7

15 years ago
updating summary
Summary: Plugins don't render in print preview → Plugins/applets don't render in print preview
(Reporter)

Comment 8

15 years ago
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

Updated

15 years ago
Target Milestone: mozilla1.2alpha → mozilla1.2beta

Comment 9

15 years ago
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
(Reporter)

Updated

15 years ago
Target Milestone: mozilla1.2beta → mozilla1.3alpha

Comment 10

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

Updated

15 years ago
Keywords: topembed → topembed-
(Reporter)

Comment 11

15 years ago
this is print preview only

Updated

15 years ago
Blocks: 176349

Updated

15 years ago
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. ***

Updated

13 years ago
Blocks: 248936
*** Bug 261449 has been marked as a duplicate of this bug. ***
*** Bug 264239 has been marked as a duplicate of this bug. ***

Comment 16

12 years ago
*** Bug 324001 has been marked as a duplicate of this bug. ***

Comment 17

12 years ago
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.

Comment 18

12 years ago
*** Bug 319630 has been marked as a duplicate of this bug. ***

Comment 19

12 years ago
*** 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.

Comment 22

10 years ago
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.

Comment 24

10 years ago
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.

Comment 25

10 years ago
(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.

Updated

10 years ago
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

Updated

9 years ago
Duplicate of this bug: 292644

Updated

9 years ago
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?

Updated

8 years ago
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?

Comment 35

7 years ago
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)

Comment 36

7 years ago
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.

Updated

7 years ago
Duplicate of this bug: 567151

Updated

7 years ago

Comment 38

6 years ago
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

Updated

6 years ago
Duplicate of this bug: 644076

Updated

6 years ago
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
Last Resolved: 4 years ago
Resolution: --- → WONTFIX

Comment 43

4 years ago
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.

Comment 44

4 years ago
(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.