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

Need to implement the printing interface for plugins

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

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

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

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.

[nsbeta3-]. cc:ing edburns@acm.org.

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

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.

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

Here's the user relnote. Printing does not work for plugins.

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.

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

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

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

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

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

Is this the same as bug 53349?

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.

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.

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

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

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

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

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.

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

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.

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

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

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?

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.

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

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.

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

Swapping 0.9 bugs....

-->1.0

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

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

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

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?

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.

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.

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?

Triage...-->mozilla0.9.1 To nominate, clear milestone and put in keywords.

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

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.

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

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.

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

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.

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

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

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.

Not gona make it--->mozilla0.9.5

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.

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

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

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.

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?

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.

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.

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

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

Marking nsbranch+.

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!

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

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

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

Tony, what plugin did u print ?

check it in - PDT+

checked into branch, marking FIXED.

verified on 9/25 branch windows and mac build.

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?

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