Closed
Bug 53349
Opened 24 years ago
Closed 23 years ago
PDF Support Problem: Mozilla Not Calling NPP_Print (full-page)
Categories
(Core Graveyard :: Plug-ins, defect, P1)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.5
People
(Reporter: lmcquarr, Assigned: peterlubczynski-bugs)
References
()
Details
(Keywords: arch, helpwanted, relnote, Whiteboard: pdt+)
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
attinasi
:
superreview+
|
Details | Diff | Splinter Review |
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.
Now that 53122 is fixed, I can use today's build. This bug still happens.
Comment 2•24 years ago
|
||
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.
Priority: P2 → P1
Comment 3•24 years ago
|
||
confirmed. Erik, thisis the bug that you were asking about in your email today.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•24 years ago
|
||
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•24 years ago
|
||
Adding attinasi, peterl to cc-list.
Comment 6•24 years ago
|
||
Nom. rtm and marking [nsbeta3-] as I assume this won't make nsbeta3. (eng:
Change to nsbeta3+ if you get a fix in time!)
Keywords: rtm
Whiteboard: [nsbeta3-]
[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.
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm-]
Target Milestone: --- → Future
Comment 8•24 years ago
|
||
Does this mean that NPP_Print doesn't get called for any plugin? or just
fullscreen plugins?
Comment 10•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
*** Bug 62459 has been marked as a duplicate of this bug. ***
Comment 13•24 years ago
|
||
We WANT to fix this.
Is anyone planning to implement printing support for plugins?
Can someone give us pointers where to start?
Comment 14•24 years ago
|
||
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
Assignee | ||
Comment 15•24 years ago
|
||
Is this the same as bug 27478. Should they be consolidated?
Comment 16•24 years ago
|
||
Maybe, but I think it would make sense to keep two different bugs for embed and
full-page modes.
Comment 18•24 years ago
|
||
Nom. nsbeta1 as this is a backward-compatibility bug for Acrobat and
high-quality support for major plug-ins is a priority for embedding.
Keywords: nsbeta1
Assignee | ||
Comment 21•24 years ago
|
||
I think I can fix this like the other bug, stealing...but for 1.0
Assignee: av → peterlubczynski
OS: Windows 2000 → All
Hardware: PC → All
Target Milestone: mozilla0.9 → mozilla1.0
Assignee | ||
Comment 22•24 years ago
|
||
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.
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.1
Comment 23•24 years ago
|
||
Do you see any JavaScript errors when you try to print?
Assignee | ||
Comment 24•24 years ago
|
||
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•24 years ago
|
||
*** Bug 76549 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 26•24 years ago
|
||
Printing plugins won't make the 0.9.1 boat unless I get more cycles.
Target Milestone: mozilla0.9.1 → mozilla1.0
Keywords: nsenterprise
Assignee | ||
Updated•24 years ago
|
Target Milestone: mozilla1.0 → mozilla0.9.4
Assignee | ||
Comment 27•24 years ago
|
||
Assignee | ||
Comment 28•24 years ago
|
||
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•24 years ago
|
||
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?
Assignee | ||
Comment 30•24 years ago
|
||
>> "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?
Reporter | ||
Comment 31•24 years ago
|
||
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
Reporter | ||
Comment 32•24 years ago
|
||
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?
Assignee | ||
Comment 33•24 years ago
|
||
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.
Depends on: 90256
Summary: PDF Support Problem: Mozilla Not Calling NPP_Print → PDF Support Problem: Mozilla Not Calling NPP_Print (full-page)
Updated•23 years ago
|
Keywords: nsenterprise → nsenterprise+
Keywords: mozilla0.9.4
Assignee | ||
Comment 34•23 years ago
|
||
Not gona make it--->mozilla0.9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Assignee | ||
Comment 35•23 years ago
|
||
Comment 36•23 years ago
|
||
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•23 years ago
|
||
r=av. But this patch alone will not fix the bug, it should be synoptic with the
patch from bug 27478.
Comment 38•23 years ago
|
||
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
Attachment #49613 -
Flags: superreview+
Assignee | ||
Comment 39•23 years ago
|
||
Patch checked into trunk along with the patch from bug 27478.
Whiteboard: [seeking reviews] → [patch in trunk]
Comment 41•23 years ago
|
||
if the fix on the trunk looks good, lets get this into the branch. Marking pdt+
Whiteboard: [patch in trunk] → pdt+
Assignee | ||
Comment 42•23 years ago
|
||
grega: bug 27478 also needs a pdt+ because this patch is dependant on that one.
Assignee | ||
Comment 43•23 years ago
|
||
checked into branch, marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 44•23 years ago
|
||
Cool! Great! Thank you!
Comment 45•23 years ago
|
||
yeah works now . verif on win ,mac branhc0925. adding vtrunk
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•