53349 - PDF Support Problem: Mozilla Not Calling NPP_Print (full-page)

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P1)

Description

[lmcquarr]

Using the M17 win build (current build is completely broken with respect
to using PDF files), when PDF is in the browser window, and you select
the PRINT menu item from the mozilla menu bar, mozilla never calls
NPP_Print.  

Printing is very, very important to Acrobat users.  There is a printer
toolbar button in the Acrobat window where they can get access to the
print functionality, but the lack of support for the print menu
item to NPP_Print is a big step backwards as far as Netscape
plug-in API support.

Comment 1

[lmcquarr]

Now that 53122 is fixed, I can use today's build.   This bug still happens.

Comment 2

[ekrock's old account (dead)]

Setting to P1 as this is a high profile partner. It's also high profile backward 
compatibility--Acrobat is the #2 most widely-used plug-in on the web per Hotbot, 
and the #1 use for Acrobat is representing complex forms for printing by the 
user. If we fail to print Acrobat pages, we're failing to support the most 
common use of Acrobat on the web.

Comment 3

[shrirang khanzode]

confirmed. Erik, thisis the bug that you were asking about in your email today.

Comment 4

[ekrock's old account (dead)]

I need to acknowledge for PDT team's reference that there is a workaround for 
this bug (using the print button on the Acrobat toolbar instead of the Moz/N6 
toolbar print button), so one option would be to document this in the release 
notes if we lack the resources to implement this fix by RTM. Nonetheless, I'd 
like to see an engineering/QA assessment of how hard it would be to fix this 
bug before we make a decision either way.

Comment 5

[karnaze (gone)]

Adding attinasi, peterl to cc-list.

Comment 6

[ekrock's old account (dead)]

Nom. rtm and marking [nsbeta3-] as I assume this won't make nsbeta3. (eng: 
Change to nsbeta3+ if you get a fix in time!)

Comment 7

[av (gone)]

[This is ekrock.] Liz, I'm really sorry, but Andrei is overwhelmed with plug-in 
crashers and other stop-ship issues. As much as we'd like to fix this for RTM, 
we lack the resources for bugs like this that have a workaround (clicking the 
Print button on the Acrobat toolbar). Future.

Comment 8

[Mike Kaply [:mkaply]]

Does this mean that NPP_Print doesn't get called for any plugin? or just 
fullscreen plugins?

Comment 9

[av (gone)]

It doesn't get called for any plugin.

Comment 10

[Mike Kaply [:mkaply]]

OK, so how would we go about implementing this for Mozilla.

I can't believe NS6 would ship without the ability to print Java applets.

Comment 11

[av (gone)]

We should not mix two different issues here. Not calling NPP_Print by itself is 
not preventing the area occupied by a plugin from being printed. Plugin just 
will not know that printing occurs. But bits (pixels) should still be printed. 
And they are currently not as far as I know, but this is not the plugin API 
issue.

Comment 12

[Fabian Guisset]

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

Comment 13

[Mike Kaply [:mkaply]]

We WANT to fix this.

Is anyone planning to implement printing support for plugins?

Can someone give us pointers where to start?

Comment 14

[av (gone)]

I think some code should be added to nsObjectFrame::Paint in nsObjectFrame.cpp
1. see if the context is actually printing context
2. call NPP_Print
3. check for return value and print off screen bits if FALSE

That's for embedded plugins. For full-page -- nsPluginViewer.cpp

Comment 15

[Peter Lubczynski]

Is this the same as bug 27478. Should they be consolidated?

Comment 16

[av (gone)]

Maybe, but I think it would make sense to keep two different bugs for embed and 
full-page modes.

Comment 17

[av (gone)]

Setting mozilla0.8

Comment 18

[ekrock's old account (dead)]

Nom. nsbeta1 as this is a backward-compatibility bug for Acrobat and
high-quality support for major plug-ins is a priority for embedding.

Comment 19

[timeless]

looks like we missed the 0.8 boat.

Comment 20

[karnaze (gone)]

Moving to Mozilla0.9

Comment 21

[Peter Lubczynski]

I think I can fix this like the other bug, stealing...but for 1.0

Comment 22

[Peter Lubczynski]

I think my print call is being lost somewhere in Javascript land for full-page 
plugins. When I click print, nothing happens. A normal page's print points that 
a WindowInternalPrint() is dispatched through JS.

The Print methods in nsDocumentViewer and nsIContentViewerFile 
[PluginViewerImpl] never get called for full page plugins. 

I think the problem may be in JS as I see my click [of the XUL print button] but 
it looks like I'm being re-targeted or something else the wrong way and I got 
lost in that code. In any case, WindowInternalPrint() is never called and I need 
it to be.

I have code in my tree for hooking up printing on the plugin side as long as I 
get a print in my nsIContentViewerFile::Print

Jonny, 
if this is you, could you take a quick look to see if we're bailing at the wrong 
spot?
Thanks!

Accepting, re-targeting for mozilla 0.9.1 and cc:ing a bunch of people.

Comment 23

[Johnny Stenback (:jst)]

Do you see any JavaScript errors when you try to print?

Comment 24

[Peter Lubczynski]

Looked at the Javascript console, no warnings or errors. Nothing on the debug 
console either. Just silently fails.

Note: One can still print PDF files by clicking the printer icon on the Acrobat 
toolbar in full-page mode.

Comment 25

[dcone (gone)]

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

Comment 26

[Peter Lubczynski]

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

Comment 27

[Peter Lubczynski]

Attachment: first try, ugly and not working yet (export nsDeviceContextSpecWin.h from gfx)

Comment 28

[Peter Lubczynski]

That's a very raw patch (for Windows only) to at least get the call from File |
Print to go to the full-page plugin. But, it crashes soon thereafter, deep
inside Acrobat. I'm not quite sure what else I'm missing. Liz or Andrei, could
you take a look?

Also, to get this to work, you'll need to export nsDeviceContextSpecWin.h from
makefile.win in the gfx src directory.

Comment 29

[av (gone)]

Peter, I don't think creating hdc is right thing to do, we should probably use 
whatever is already created for printing. If I am not missing something in my 
turn, I remember getting into this problem when doing this for embed mode. And I 
introduced a new method nsIRenderingContext::RetrieveCurrentNativeGraphicData 
(see nsObjectFrame::Print). Maybe you can use this too?

Comment 30

[Peter Lubczynski]

>> "whatever is already created for printing"

There is nothing created for printing at this point, at least not for full-page
plugins. The print message comes down directy from nsGlobalWindowImpl.cpp to
nsPluginViewer.cpp, no printer hdc is created at this point. In printing a
normal document, the call goes to nsDocumentViewerImpl instead which has tons of
code to prepare for printing a document. With Don's help, I ripped out some of
that same code in this patch but it'll have to be cleaned up, perhaps being more
XP. But for a full-page plugin, we don't have the printer hdc so I think we need
to create it (or perhaps Acrobat needs to create it, Liz?). This may get a
little tricky for full-page plugins in frames.

There is no nsObjectFrame::Print(),yet, however, I think using your
nsIRenderingContext::RetrieveCurrentNativeGraphicData() method in
nsObjectFrame::Paint() would works GREAT in the embedded case in bug 27478.
That'll make it easier to fix that bug. Have you done any other helpful work on
that bug or this bug?

Comment 31

[lmcquarr]

Hi folks:

I was out of town for a few days.  It will take me a day or two to
catch up and take a look at this.

Liz

Comment 32

[lmcquarr]

Do you still need my help on this?  After reviewing the notes,
it looks like you still were having trouble hooking this
up to a full window plug-in, right?

Comment 33

[Peter Lubczynski]

Liz, thanks but I think this needs more work. Since the patch in bug 90256 looks
like it will totally rearrange all the full-page plugin code, this will probably
wait until that is finished. However, I have moved on to bug 27478 which is the
embedded part of the printing problem.

Comment 34

[Peter Lubczynski]

Not gona make it--->mozilla0.9.5

Comment 35

[Peter Lubczynski]

Attachment: better patch to hook up calling NPP_Print (depends on bug 27478) for full-page plugins v.1

Comment 36

[grega]

This was originally marked nsenterprise+, how often will ent customers run into
this?  How close are we to a complete fix?  Should we take this one on the branch?

Comment 37

[av (gone)]

r=av. But this patch alone will not fix the bug, it should be synoptic with the 
patch from bug 27478.

Comment 38

[Marc Attinasi]

Comment on attachment 49613 [details] [diff] [review]
better patch to hook up calling NPP_Print (depends on bug 27478) for full-page plugins v.1

sr=attinasi

Comment 39

[Peter Lubczynski]

Patch checked into trunk along with the patch from bug 27478.

Comment 40

[Patrick C. Beard]

Marking nsbranch+.

Comment 41

[grega]

if the fix on the trunk looks good, lets get this into the branch.  Marking pdt+

Comment 42

[Peter Lubczynski]

grega: bug 27478 also needs a pdt+ because this patch is dependant on that one.

Comment 43

[Peter Lubczynski]

checked into branch, marking FIXED.

Comment 44

[lmcquarr]

Cool!  Great!  Thank you!

Comment 45

[shrirang khanzode]

yeah works now . verif on win ,mac branhc0925. adding vtrunk