406061 - Plugin's QuickDraw port not current when NPP_HandleEvent is called

Status: RESOLVED INVALID

(Core Graveyard :: Plug-ins, defect)

Description

[Michael Wolfinbarger]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-us) AppleWebKit/523.10.3 (KHTML, like Gecko) Version/3.0.4 Safari/523.10
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b1) Gecko/2007110903 

In previous versions of Firefox, the current QuickDraw port was set to the plugin's port by the browser prior to calling NPP_HandleEvent. In this build, the current QuickDraw port is not being set. The NPAPI docs say:

"When NPP_HandleEvent is called, the current port is set up so that its origin matches the top-left corner of the plug-in. A plug-in does not need to set up the current port for mouse coordinate translation."

My initial interpretation was that the current port would be set to the plugin's port on entry to NPP_HandleEvent. However, I now think this statement implies that but doesn't explicitly state it. This is either a bug in the docs or in the current build.

At worst, the new build is inconsistent with the docs. At best, the docs are imprecise and the current build is inconsistent with previous builds.

Bottom line is that any existing plugins that assume the current port is set on entry to NPP_HandleEvent do not behave correctly with this build.


Reproducible: Always

Steps to Reproduce:
1. Check the current QuickDraw port by calling QuickDraw's GetPort API upon entry to NPP_HandleEvent in Firefox 2.x and compare it to the plugin's port as provided in the NP_Window structure.
2. Repeat for Firefox 3.0b1.

Actual Results:  
In Firefox 2.x, the current QuickDraw port is set to the plugin's port upon entry to NPP_HandleEvent for a mouseDown or mouseUp event. In this Firefox 3 build, the current QuickDraw is not set to the plugin's port.

Expected Results:  
I expected the current QuickDraw port to be set to the plugin's port upon entry to NPP_HandleEvent. Alternatively, I expected the NPP_HandleEvent documentation to be more explicit in specifying the state of the current QuickDraw port upon entry to NPP_HandleEvent.

Comment 1

[Damian Frank]

This is paraphrased from my comment in 421026, but I believe this bug ticket is a much more specific ticket for the problem we're having:

I work on a plugin that also has this problem.  We (unfortunately) have to use QuickDraw to use CopyBits.  This definitely needs attention, because even if I set the port to the one given to us (via NPP_SetWindow), the clipping for that port is incorrect; the top portion of the page content area is clipped and not drawn to.

Can I safely assume that this is not our bug and will be fixed in Firefox? 
(Our plugin works fine with 2.x, of course.)  Thanks.

Comment 2

[Damian Frank]

Just to be clear, this is a big problem.

* If plugins assume the port is already set, they draw on the desktop, scribbling over other windows.

* If we set the port manually to what's given to us in NPWindow, it's still screwed up; the clipping and transformation values are incorrect, resulting in the top portion of the plugin area not rendering.  (In embedded plugins, I also see that the offset is strange; it changes as you scroll, but it changes too much.)  Maybe it's possible to come up with the right Quickdraw incantations to enforce the proper setup for the port, but it's not at all clear to me.

I would expect this to break any and all plugins that rely on Quickdraw, which is pretty much every plugin not expressly written for 3.0 or using some other hack to draw.  I don't know what the Mozilla team's criteria are, but I wonder why this wouldn't be considered blocking.  It seems pretty heinous to me.  (I'd expect it to be a relatively simple fix too, but I could be wrong.)

Comment 3

[Josh Aas]

Closing this out, we don't support the Quickdraw drawing model any more.