27478 - Cannot print plugin on page

Status: VERIFIED FIXED

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

Description

[shrirang khanzode]

Used windows commercial build (2000021108m14)

1.Install and launch the browser
2.Go to the url mentioned above
4.Observe a web page with shockwave plugin appears.
3.Once the plugins starts to play, select menu option FILE->PRINT to print the     
page
4.Observe that the plugin does not print and a grey square of the size of the     
plugin prints out.

  Page prints well in 4.7

Comment 1

[dcone (gone)]

Need to implement the printing interface for plugins

Comment 2

[leger]

Putting on PDT- radar for beta1.  Will relnote...adding that keyword.

Comment 3

[av (gone)]

Reassigning to the component owner, to decide who should own this.

Comment 4

[dcone (gone)]

I know some plugins print.. so it must be specific to this plug in.. or and API, 
not sure.

Comment 5

[kenneth buttler]

this is a stale bug . it hasn't been touched in 30 days i have retested it with
2000072608 buildon win NT. this bug still reperduces in exactly the same way as
discribe by original reported.

Comment 6

[ekrock's old account (dead)]

[nsbeta3-]. cc:ing [e-mail]. 

Comment 7

[ekrock's old account (dead)]

Note that there are two parts to fixing this:
a) easy part: implementing notification so plug-in can handle printing
b) hard part: finishing Moz Plug-in API so we can print plug-in content

Comment 8

[edburns]

I find that nsIPluginInstance::Print*() is not called when you do print.  As
Eric points out.  This is the easy part.  Still, I'd like to see it for PR3.

Comment 9

[Gervase Markham [:gerv]]

I've seen plugin-printing bugs elsewhere, so it could be that this one is a 
relic. So:

It seems unclear to me whether this bug requires either of a "developer" or 
"user" release note for Netscape 6 RTM. If anyone feels it does, can they please 
draft one and then nominate with the relnote-user or relnote-devel strings in 
the Status Whiteboard.

Thanks :-)

Gerv

Comment 10

[edburns]

Here's the user relnote.

Printing does not work for plugins.  

Comment 11

[Peter Lubczynski]

I just talked with Don Cone about this and plugins don't print because 
ObjectFrames don't know that they are being printed versus displayed on the 
screen. Therefore, ns4xPluginInstance::Print() is never called.

One possible way to do this would be in nsObjectFrame:Paint() to check if 
aPresContext is a PrintContext then tell the plugin instance to print.

Comment 12

[av (gone)]

And we should just print the screen bits if the plugin refuses to do the job.

Comment 13

[timeless]

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

Comment 14

[timeless]

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

Comment 15

[Matthias Versen [:Matti]]

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

Comment 16

[Boris Zbarsky [:bzbarsky]]

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

Comment 17

[Peter Lubczynski]

Is this the same as bug 53349?

Comment 18

[admin]

Does anyone know if this problem is solved yet? It happens to Applets also. 
Applet printing is VERY important to some E-Commerce sites.

Steps to Reproduce:
1. With NS 6; Open 
http://www.hcc.cc.fl.us/services/faculty/wayne_pollock/Java/TempConv/TempConv.ht
m
or
http://www.idautomation.com/java/LinearAppletExample.html
2. Print the screen to a printer
3. Look at the output
Actual Results:  Applets displayed on the screen do not print.
Expected Results:  They should print - I am printing the screen.

Comment 19

[Joe Chou]

54194 (printing applet crashed browser, a show-stopper for OEM release) has just
been reopened, due to the reason that the patch in 54194 did not fix the crash
in all cases. The root cause of 54194, as stated in the previous comments in
27478, is that the plugin's Print() was not called, instead, a plugin instance
was instantiated (which created a null superwin causing the crash).
The fix of 27478 (to call plugin to print instead of instantiating a plugin
instance to draw) should fix 54194 for good.
Can we have this bug fixed ASAP, please. 

Comment 20

[shrirang khanzode]

well, it's been futured and I can't change the milestone myself.

Comment 21

[Joe Chou]

Any objection to change the Target Milestone of this bug to the next release
(mozilla0.8?)?

Comment 22

[edburns]

Added mozilla1.0 keyword.  AV, can you please adjust the milestone?

Thanks,

Ed

Comment 23

[Joe Chou]

Hi guys, can we change the milestone to the next available release, so that this
bug can be fixed soon?

Comment 24

[Peter Lubczynski]

It'd be great to do this by mozilla 0.8 but I don't think we have the resources 
for that.  Anyone wana help?

I'm setting the milestone for 0.9.

Comment 25

[shrirang khanzode]

spam : changing qa to sujay (new qa contact for Printing)

Comment 26

[Joe Chou]

FYI:
Currently, on the Java plugin side, the embeded plugin print method has been
implemented only on Windows. The Unix version is planned to be implemented in
Java plugin 1.4 release. Therefore, it would make sense if the problem can be
fixed on Windows first, then ported to other platforms.

Comment 27

[Doug Rothert]

Just adding my 2 bits for the IBM Java Plugin team... We are
blocked on printing with our Java Plugin on NT, Linux, and OS/2
because of this defect. Hopefully it can be resolved quickly
so that we can print applets in the future. 

thanks, 
-Doug Rothert

Comment 28

[drapeau]

Adding Java Plug-In folks to the interest list on this bug.

Comment 29

[av (gone)]

I am trying to add calling NPP_Print as a first step to fix the printing issues. 
Can anyone attach a test case where a plugin or Java applet expects this call so 
I can test my changes?

Comment 30

[Joe Chou]

One test case can be printing "java.sun.com", which has two applets. Let the
page loaded first, then click the Print icon. Currently the printed page leaves
the applets areas blank.

Comment 31

[av (gone)]

Just to make sure, I need the applet to take over in response to NPP_Print. Is 
this a case?

Comment 32

[Peter Lubczynski]

Possible solution:

In nsObjectFrame::Paint do a QueryInterface on aRenderingContext to see if it's 
a nsIPrintContext. If so, call nx4xPluginInstance::NPP_Print and return.

But first, NPPrint* PrintInfo would have to set up according to what the spec 
says:
     
http://developer.netscape.com/docs/manuals/communicator/plugin/pgfns.htm#1007028

There is plenty of stuff there that explains how this should work for Windows, 
Mac, and Unix. It looks like we just pass off the NPWindow handle in the embedd 
case. This gives us a hWnd on Windows and a GraphPort on Mac. 

Don, could you show some example of code for how to grab the bits off the screen 
from an hWnd and a GraphPort and send them to the nsIPrintContext?


PROBLEM: From what I understand about printing, a whole new frame model is 
constructed. We need the NPWindow struct of the plugin instance which is 
visible, not the one created by the frames for printing. So, to perhaps get the 
current plugin on the screen and not create another instance, we need to be sure 
we past in the correct NPP instance, right? Perhpas we can call 
nsActivePluginList::FindPluginForURL or something like that to get the correct 
instance by using the URL for the plugin we are going to print as an argument.

What do you think of this strategy. Should work for Applets as well.

Comment 33

[Peter Lubczynski]

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

Comment 34

[Peter Lubczynski]

Swapping 0.9 bugs....

Comment 35

[Peter Lubczynski]

-->1.0

Comment 36

[av (gone)]

BTW, Peter, are you also going to look at full-page plugins?

Comment 37

[Peter Lubczynski]

The solution for full page plugins is even easier. There is a Print method in 
nsIContentViewer (or nsIDocumentViewer) which is called if the user prints. In 
there I set up the NPPrint struct for a full-page plugin case and pass it on to 
NPP_Print just like with embedded.

Correct me if I am wrong, but as long as we have the print entry point, all we 
then should try to do is a SAFE call into the plugin to print???

A good question is about Java. George, how will Java deal with this? Do I need 
to check if my plugin is an applet?

Nominating nscatfood

Comment 38

[av (gone)]

We should also check the return to see if plugin refuses to print and throw 
off-screen bits.

Comment 39

[Joe Chou]

The interface call should be nsIPluginInstance::Print(nsPluginPrint*
platformPrint), and I believe the plugin has to be an applet, since this is
printing an applet's contents. Stanley, anything to add?

Comment 40

[stanley.ho]

When I browsed through the printing code, the browser was trying to call 
everything in the document model to be printed three times - lower layer, 
middle layer and upper layer, assuming that this is part of the DHTML 
properties. However, for Java object, we only need to be called once.

Comment 41

[drapeau]

peter: I've asked Joe and Stanley to reply to your question.  They have both
posted comments; do either/both of them answer your question?  If not, let us
know in the bug comments.

Comment 42

[Peter Lubczynski]

So Stanley/Joe: 

I should be able to call fCallbacks->print and the OJI plugin will take care of 
dispatching printing based on my NPPrint I pass in?

Comment 43

[Peter Lubczynski]

Triage...-->mozilla0.9.1

To nominate, clear milestone and put in keywords.

Comment 44

[Arun Ranganathan]

Bug 53349 is critical (since printing from the acrobat plugin is key in many
online applications -- e.g. taxes) and so marking this critical (note the
dependency tree).

Comment 45

[Peter Lubczynski]

Note Arun: one can still easily print Acrobat PDF documents by clicking the 
printer icon in the Acrobat toolbar. 

This bug has to do with printing a plugin in-line and bug 53349 wants our File | 
Print to call NPP_Print correctly for full-page documents.

Comment 46

[Peter Lubczynski]

Printing plugins won't make the 0.9.1 boat unless I get more cycles.

Comment 47

[admin]

Can someone please give me the status of the Java Applet Print Problem? We have 
customers that use our BARCODE applets to allow their customers to print 
receipts, coupons and other barcoded items from their browser. If this does not 
get resolved soon it is going to be a serious issue.

This is the problem:
When printing the screen, applets do not print. Screens print OK on all 
versions of IE and NS 4.x. The yfail to print on NS 6 and the Netscape rep told 
it is Mozilla related.

Steps to Reproduce:
1. With NS 6; Open 
http://www.hcc.cc.fl.us/
services/faculty/wayne_pollock/Java/TempConv/TempConv.htm
or
http://www.idautomation.com/java/LinearAppletExample.html

2. Print the screen to a printer
3. Look at the output

Result:  Applets displayed on the screen do not print.
Expected Results:  The should print - I am printing the screen.

Someone please give the status and when they will be implemented in Netscape 6 
and IE 5.5.  Thanks!!

Brant Anderson, IDAutomation.com, Inc.

Comment 48

[admin]

This is my second try to get the status of Bugzilla bug #27478. I received no 
response to my last plea for a status update. Is anyone working on this anymore?

The problem is that an applet that displays an image on the screen is not 
printing in the latest version of Netscape 6 and they tell me the problem is 
with Mozilla. This is an example:
http://www.idautomation.com/java/LinearAppletExample.html

Can anyone provide me with a status update?

Regards,

Brant Anderson
IDAutomation.com

Comment 49

[edburns]

Thanks for taking the time to look at this.

I'm sorry we haven't done anything with it.

We've had some resource problems.

Comment 50

[Peter Lubczynski]

The bug keeps slipping milestones due to more important bugs like crashers.
However, I did talk with Don Cone and Av about plugin printing last week and I
have an idea of how to fix this bug along with bug 53349. They will probably be
fixed at the same time.  I estimate that this bug will probably either make this
milestone or the next.

Mozilla does accept patches from outside contributors. There is a starter patch
in bug 53349 if anyone is interested in getting this to work sooner ;)

Comment 51

[Peter Lubczynski]

Attachment: patch to get simple testcase to print on Win32

Comment 52

[av (gone)]

Great investigative job, Peter. Nice patch, I think we at last have something.
r=av

Comment 53

[Peter Lubczynski]

Wooo...hold on there, there's quite a bit more that need to be done before this
can be checked in. My next patch should actually get a simple testcase to print
in the correct location and be the correct size with different kinds of
printers. However, there still these MAJOR issues:

1) Reflow() does NOT calculate the size of the plugin correctly for printing at
all!! It's way off and I bet this is causing MANY bugs (like the hang when
printing Disney.com).

2) Sometimes |shell->GetPrimaryFrameFor()| does not return an ObjectFrame like
exptected. It's sometimes an inline so I need to figure out what's REALLY going
on and how to get the correct frame.

3) Mac needs to be tested. We are getting the DC in a XP way, so in theory it
should just work with a THPrint correctly. I think the code is mostly XP except
for the NPPrintCallbackStruct on UNIX. Fixing printing on UNIX may be a little
more work as we need to somehow give the plugin the path to the postscript FILE
that we are printing to.

4) Full-page printing. I may not be able to get this right away and that whole
code may be changing anyway. See bug 90256 and bug 73846. 



I have some idea on how to fix #1 above. The problem seems to be that in
nsObjectFrame::GetDesiredSize() seems to ONLY calculate the correct size if we
have an nsPluginInstanceOwner. Does ANYONE know WHY this is so? There is some
REALLY funny math in this function that sets the width equal to the height. I
propose changing this to correctly determine the size the on the FIRST reflow by
cleaning up and moving GetWidth/GetHeight back into the ObjectFrame.

Comment 54

[Peter Lubczynski]

Attachment: slightly better patch (but don't get your hopes up)

Comment 55

[Peter Lubczynski]

Attachment: latest and greatest patch (big changes, please test) v.3

Comment 56

[Peter Lubczynski]

Not gona make it--->mozilla0.9.5

Comment 57

[Peter Lubczynski]

Please try that last patch. It's just about there.

The percent sizing still needs a little work, but I'm talking with Marc about that.

Bug 97563 now blocks this bug. We totally hang while trying to print an <embed>
inside any simpe table.

Comment 58

[edburns]

How can I test this?  Is this only for old school plugins?

Comment 59

[edburns]

Peter, can you produce another patch?  I tried patching this one, but it didn't 
work:

patch -i nsObjectFrame.cpp.patch nsObjectFrame.cpp
patching file `nsObjectFrame.cpp'
Hunk #3 succeeded at 243 (offset 2 lines).
Hunk #4 FAILED at 738.
Hunk #5 succeeded at 1499 (offset 3 lines).
Hunk #6 succeeded at 1763 (offset 2 lines).
Hunk #7 succeeded at 2736 (offset 12 lines).
1 out of 7 hunks FAILED -- saving rejects to nsObjectFrame.cpp.rej

Comment 60

[Peter Lubczynski]

Yeah, after last night's landing this patch now has hunks that fail. I'm working
on a new one now as I've found some problems. The patch will call
nsIPluginInstance->Print so as long as your plugin implements that, it will pass
in values like 4.x.

Comment 61

[Peter Lubczynski]

Attachment: updated patch to tip (please try, works well on Windows) v.4

Comment 62

[Peter Lubczynski]

Attachment: updated patch with Mac and UNIX changes (please test and review) v.5

Comment 63

[av (gone)]

Wow! What a work! And nice clean up in object frame sizing code.

Peter, what is the purpose of the several lines if code after your comment
'XXX Nav 4.x always sent a SetWindow call after print' at the bottom of
nsObjectFrame::Paint() method?

Comment 64

[edburns]

I'm very happy to report that this works for me on Win32.  Unfortunately, I 
can't say I feel qualified to review this code.  

Comment 65

[Peter Lubczynski]

Well, in my testing, I found that on Win32, 4.x would do this strange behavior
of calling SetWindow after calling Print. I thought it would be a good idea
and easy to duplicate to keep backwards compatibility as close as possible.
However, I couldn't find anything in the published spec about this call and it
didn't look apprent in the old 4.x source.

I feel pretty good about the patch on Winodws and I can test on Mac, but I'd
like some help in testing UNIX. Even though I copied some of the UNIX code
directly from the 4.x source, there still may be inconsistencies like I found on
Windows and Mac by experimentation.

Comment 66

[Peter Lubczynski]

Attachment: cleaning up and fixing bugs on Mac, v.6

Comment 67

[Peter Lubczynski]

Attachment: slightly modifed patch for UNIX, v.6

Comment 68

[Peter Lubczynski]

That final patch is a complete patch to make embedded-style plugins print
correctly on Windows and Mac Classic. Please review as I think it's ready now.

I had some problems even getting 4.x to print the plugin so I wasn't able to get
it working in Mozilla either. Perhaps we should open a new bug on this, maybe if
someone has steps on getting 4.x to print plugins I can get Mozilla to do the same.

Comment 69

[av (gone)]

Comment on attachment 48954 [details] [diff] [review]
slightly modifed patch for UNIX, v.6

r=av

Peter, what should we do if  some plugin does not care about printing and simply ignores the NPP_Print call? What does 4.x do?

Comment 70

[Marc Attinasi]

Comment on attachment 48954 [details] [diff] [review]
slightly modifed patch for UNIX, v.6

sr=attinasi - please get the platform experts to check the plat-specific parts.

Comment 71

[Peter Lubczynski]

Attachment: checked-in patch

Comment 72

[Peter Lubczynski]

Patch checked in to the trunk with minor changes from beard and /~~~ removed.

Comment 73

[Patrick C. Beard]

Marking nsbranch+.

Comment 74

[grega]

sujay, have you had a chance to look at this in a trunk build?  We want this fix
on the branch but i want to make sure it has been verified on the trunk.  Thanks!

Comment 75

[shrirang khanzode]

This is shrirang! I tested on his behalf..on mac and windows, the patch looks 
great on the trunk.

Comment 76

[Tony Yuan]

I tested it and found the plugin window was printed out,
but had wrong size and position. Thanks.

tony

Comment 77

[Peter Lubczynski]

Details please....

1) Testcase
2) Platform
3) Plugin
4) Printer
5) Build ID

Comment 78

[shrirang khanzode]

Tony, what plugin did u print ?

Comment 79

[Jaime Rodriguez, Jr.]

check it in - PDT+

Comment 80

[Peter Lubczynski]

checked into branch, marking FIXED.

Comment 81

[sujay]

verified on 9/25 branch windows and mac build.

Comment 82

[Joe Chou]

I tried on Windows XP with moz1.0rc2 and JRE 1.4.1, and the test page
(java.sun.com) applets were not printed (just used File->Print Preview). On the
other hand, IE or ns4.7x seemed to be working (applets got printed).

Am I missing something here? 

Comment 83

[Peter Lubczynski]

Joe, Print Preview is disabled for plugins. Try actually printing to a real
printer (or something like Ghostscript or PDF Writer).