388082 - Printing plugin on OS X on trunk causes crash

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Steven Michaud [:smichaud] (Retired)]

As best I can tell, you always crash when you try to print a page with
at least one plugin in trunk versions of all Mozilla.org browsers on
OS X.

Well almost always:  You don't crash when you try to print a page
containing a Java plugin ... but that's only because the JEP doesn't
yet support printing :-)

Aside from Java, I always crash trying to print either Flash plugins
(e.g. http://rogerdean.com/) or QuickTime plugins (e.g. any of the
QuickTime movie trailers at http://www.apple.com/trailers/).  I've
tested in Minefield and Camino (though not yet in SeaMonkey).

Crashes don't happen on the 1.8 branch, but no plugins print (you see
blank spots where they should have printed).  This was also the
behavior on the trunk until the 2005-08-23-07-trunk nightly.  On that
date changes were made to layout/generic/nsObjectFrame.cpp to "move
native theme stuff to widget (bug 305291) and land the remaining
thebes gfx changes (bug 305538)":

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/layout/generic&
command=DIFF_FRAMESET&file=nsObjectFrame.cpp&rev1=1.513&rev2=1.514&root=/cvsroot

One of these dropped a NULL check on the call to get "native graphic
data" from the current rendering context.  But this call (both its old
and new variations) _always_ returns NULL on OS X.  So the
print.embedPrint.platformPrint field of the NPPrint structure passed
to the plugin's implementation of NPP_Print() (in
ns4xPluginInstance::Print()) is always NULL.  And neither the Flash
nor the QuickTime plugins like this at all -- they always crash.

As best I can tell the print.embedPrint.platformPrint field should
always be set to a QuickDraw port.  This is what
nsRenderingContextMac::GetNativeGraphicData() returns (if it's called
with the appropriate GraphicDataType).  But the rendering context for
all OS X trunk browsers is now an nsThebesRenderingContext object.  I
have no idea how to get an nsThebesRenderingContext object to do the
right thing (to create and return a QuickDraw port on OS X).  So my
"fix" for these crashes is just to restore the NULL check that was
dropped by revision 1.514 to nsObjectFrame.cpp.  (I'll post a patch
that does this.)

My "fix" gets rid of the crashes, but doesn't make plugin printing
work on OS X.  I'll leave it to others (who know more about this stuff
than I do) to decide how (or whether) to get plugin printing to
actually work.

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Attachment: Simple fix (landed on trunk)

Comment 2

[Steven Michaud [:smichaud] (Retired)]

Attachment: Crash in Flash plugin

Made with today's Minefield nightly (2007-07-13-04-trunk).

Comment 3

[Steven Michaud [:smichaud] (Retired)]

Attachment: Crash in QuickTime plugin

Also made with today's Minefield nightly (2007-07-13-04-trunk).

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Steven: What's the status here? Do you need reviews?

Comment 5

[Steven Michaud [:smichaud] (Retired)]

> What's the status here?

My patch gets rid of the crash (which as far as I know only happens on
OS X), but doesn't make plugin printing work.

And it needs to be tested on Windows (which I'm not able to do myself).

(Since my change is on the "other side" of a "#if defined(XP_UNIX) &&
!defined(XP_MACOSX)", it doesn't effect other OSes.)

Plugin printing doesn't work in Wiudows either (on the trunk), though
it does work in Windows on the branch (at least for the Flash object I
just tested with).

Plugin printing doesn't even work on the branch in Mac OS X.

So (aside from the need to test on Windows) the question is -- is my
patch "good enough", or does someone need to take the trouble to make
plugin printing work on OS X (and on Windows)?

If no-one cares about plugin printing even on Windows, I suppose the
answer should be "yes" (my patch can be used as it stands).

> Do you need reviews?

I suppose I do.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Stuart/vlad: Is printing plugins a known issue? Do we have any other bugs on it?

Comment 7

[Steven Michaud [:smichaud] (Retired)]

It's possible that plugin printing hasn't worked on Mac OS X for
years.  See bug 191046.

NPP_Print _is_ now being called on the trunk (on OS X) ... with the
results that I've reported here.

As I said above, plugin printing does work on the branch in Windows.
But just now I tested on Linux (with Firefox 2.0.0.5) and a blank
space showed up where a Flash plugin should have appeared (one that
prints fine with Windows Firefox 2.0.0.5).

And, as I also said, plugin printing (with the same Flash object)
doesn't work on the trunk even on Windows.

There are a few bugs that touch on these problems.  But in general it
seems that very few people try to print plugins ... or say anything
about their problems when it doesn't work.

Notice that printing a plugin has triggered a crash on the trunk on OS
X since 2005-08-23, and I'm the first one to report it (as
specifically happening on the trunk).

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 272232 [details] [diff] [review]
Simple fix (landed on trunk)

I hate this code so, so much.

Whether plugin printing should work or not is a separate issue; we shouldn't crash, so we should take this patch.  This, I think, should be safe on windows.

That said, I'm pretty sure we can make plugin printing work across the board, but that's a separate patch.

Comment 9

[Stuart Parmenter]

Comment on attachment 272232 [details] [diff] [review]
Simple fix (landed on trunk)

this patch looks fine, but this is a windows patch not a mac one.. Is this the right bug?

Comment 10

[Steven Michaud [:smichaud] (Retired)]

> but this is a windows patch not a mac one

Not so.

My change is on the "other side" of a "#if defined(XP_UNIX) &&
!defined(XP_MACOSX)" block.

And in any case I did test it on OS X :-)

It's pretty clear, though, that whoever wrote this code wasn't
thinking of OS X -- hence the NATIVE_WINDOWS_DC parameter to the
GetNativeGraphicData() call (which makes it return NULL on OS X).

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Yeah, we hit this code in the Mac case, and that returns nsnull on the mac
(always), as comment #1 says.  We need to do some extra work on XP_MAC here to
get the CGContextRef, start QuickDraw rendering, and then send QD Port down to
the plugin.  But this fix should avoid the crash at least.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

Since this bug was designated a blocker (just) before the tree closed
for the A7 release, I assume it's alright for me to land my patch
(attachment 272232 [details] [diff] [review]) once the tree reopens.  (If it reopens tonight, as
planned, I'll land the patch tomorrow morning ... assuming that I do
in fact have permission.)

Comment 13

[:Gavin Sharp [email: [e-mail]]]

You can land your patch before the tree reopens if you get approval from one of the Firefox 3 M7 drivers (schrep, mconnor; direct email or IRC probably work best).

Comment 14

[Steven Michaud [:smichaud] (Retired)]

Landed on trunk.

Comment 15

[Marcia Knous [:marcia]]

https://litmus.mozilla.org/show_test.cgi?id=5316 added to Litmus.