303470 - Java Embedding Plugin interferes with scrolling in PDF plugin

Status: RESOLVED INCOMPLETE

(Core :: Widget: Cocoa, defect)

Description

[Simon Fraser [no longer active]]

If I visit a page with Java applets, then, in another tab, view a PDF file (I
have the PDF plugin installed: http://www.schubert-it.com/plugin/), then
scrolling in the PDF plugin has lots of drawing gliches.

If I close the tab with the Java applets in, scrolling returns to normal.

Comment 1

[Manfred Schubert]

PDF Browser Plugin 2 is very picky about the QD port being set up to how it
expects it. If that is changed by someone else in another tab (or even another
instance of itself) there can be scrolling artifacts. Happens in Safari too.

I wouldn't put effort in working around this from the browser side.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

I've confirmed this in Camino 0.8.4 and 0.9a2, but not in Firefox 1.0.6 or
Deer Park Alpha 2.  Thanks for the report.

> I wouldn't put effort in working around this from the browser side.

How about from the perspective of another plugin vendor? :-)

I'm the author of the Java Embedding Plugin
(http://javaplugin.sourceforge.net/).

> PDF Browser Plugin 2 is very picky about the QD port being set up to how it
> expects it. If that is changed by someone else in another tab (or even
> another instance of itself) there can be scrolling artifacts. Happens in
> Safari too.

Any suggestions on what I might be able to do about this?  (By the way, the
Java Embedding Plugin is (basically) a Cocoa app, with some Carbon elements
thrown in to work around Apple's bugs.  I play around with drawing ports as
little as possible, and I always save and restore them.)

Comment 3

[Steven Michaud [:smichaud] (Retired)]

(By the way, I'll be gone for the next week and a half.  So I won't be able to
attend to this (or to other JEP bug reports) for a while.)

Comment 4

[Manfred Schubert]

(In reply to comment #2)
> How about from the perspective of another plugin vendor? :-)

Plugin handling should be correct of course. I meant not to put effort in
wordarounds specific to PDFP2.

> Any suggestions on what I might be able to do about this?

NPWindow and NP_Port structures should have correct port, origin and size
whenever the browser calls into the plug-in (all event handling and timers, not
just during SetWindow()). Then it should work I think.

Comment 5

[Simon Fraser [no longer active]]

(In reply to comment #4)
> (In reply to comment #2)
> > How about from the perspective of another plugin vendor? :-)
> 
> Plugin handling should be correct of course. I meant not to put effort in
> wordarounds specific to PDFP2.
> 
> > Any suggestions on what I might be able to do about this?
> 
> NPWindow and NP_Port structures should have correct port, origin and size
> whenever the browser calls into the plug-in (all event handling and timers, not
> just during SetWindow()). Then it should work I think.

For all the "explicit" plugin entry points this should already be true; if not,
file a bug (although I seem to recall that such a bug does exist).

For "implicit" calls into the plugin (e.g. in Carbon Event handlers registered
by the plugin) then I think you are on your own, and should ensure yourself that
you set the port and origin correctly.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

> I've confirmed this in Camino 0.8.4 and 0.9a2, but not in Firefox 1.0.6 or
> Deer Park Alpha 2.

I've now found that this problem happens even using Apple's Java Applet.plugin
(i.e. not using any part of the Java Embedding Plugin), or when two different
PDF documents are loaded into different tabs at the same time (but no applets
are present in any tab).

So it seems this problem isn't caused by the Java Embedding Plugin.

My latest tests (like my earlier ones) don't trigger the problem in Deer Park
Alpha 2 or Firefox 1.0.6.  I tested on Mac OS X 10.3.9.

Comment 7

[Mark Mentovai]

We had a similar bug in the core, where the TrackControl/HandleControlClick internal run loop was picking up the CFRunLoopSource and firing PLEvents that would mess with the QD state.  As a workaround, I implemented checks for unexpected QD states and forced the OS to recalculate the scrollbar position by posting a bogus mouseDown event.  You can see this in attachment 202167 [details] [diff] [review] to bug 311399.

This isn't just limited to the JEP in Camino: I'm seeing similar problems with scrolling PDFs in Firefox (Carbon widget) when things are being drawn outside of the plugin's rectangle: a caret in the URL bar while scrolling a PDF (with its scrollbar) is one way to trash a perfectly good browser window.

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Sounds like this bug is really a subset of bug 180596 (see bug 180596 comment 12-13 and bug 180596 comment 15) and we should dupe it there and modify the summary of bug 180596.

(The way that the broken redraws happen with JEP in one tab is different from the broken redraws with multiple PDFs or PDF and another plug-in type, but I assume the problem is essentially the same as with other plug-ins.)

Comment 9

[Steven Michaud [:smichaud] (Retired)]

The JEP is long gone.