288511 - Port origin is incorrectly set when sending events to plugins

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Brian Greenstone]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.5.7 (KHTML, like Gecko) Safari/125.12
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

According to the Netscape Gecko plug-in docs:

"On Mac OS, when NPP_HandleEvent is called, the current port is set up correctly so that its origin 
matches the upper-left corner of the plug-in. A plug-in does not need to set up the current port for 
mouse coordinate translation."

This proves to be true with Safari, but not with Firefox.  On Safari, when an event occurs, the mouse 
coordinates passed to NPP_HandleEvent() are relative to the plug-in's "pane".  But with Firefox, the 
mouse coordinates are always window-relative, not plug-in-relative.  This is the incorrect behavior.

Calling GetMouse() just returns the same bad mouse coordinates.  There is no way to convert these 
window coordinates into the correct plug-in coordinates, so clicking in a plug-in often has the wrong 
results if the mouse coordinates are used by the plug-in.


Reproducible: Always

Steps to Reproduce:
Create a plug-in pane in a browser window and wait for NPP_HandleEvent to be called.  The port that 
the Gecko docs refer to is the current port, so call this:

	mouseCoordInPane = theEvent->where;				
	GlobalToLocal(&mouseCoordInPane);

That should convert the global (screen) mouse coords into the plug-in's coords.  It works find in Safari, 
but not in Firefox.

Comment 1

[Doron Rosenberg (IBM)]

-> plugins

Comment 2

[Simon Fraser [no longer active]]

I believe what Firefox is doing is correct. Safari may be wrong here.

The mouse coordinates in mouse-related EventRecords are global (screen)
coordinates. The port origin is set to the top left of the plugin's pane.
You can thus get local coordinates by calling GlobalToLocal().

Comment 3

[Brian Greenstone]

Yes, the "where" field is correct - it is set in the global window coordinates.  However, it's the GrafPtr 
that is incorrectly set because calling GlobalToLocal() does *not* give you plugin-pane relative 
coordinates.  It does in Safari, but not in Firefox.  In Firefox it gives you *window* relative coordinates, 
but even then, the coordinates seem to fluctuate.

For example.  If my pane is at 100,100 in the browser window and I click on the upper-left corner of 
the plugin pane, then after calling GlobalToLocal() I should get 0,0.  That's what I get in Safari, but in 
Firefox I get 100,00 since it's giving me window-relative coordinates.  However, even this is not 
reliable:  Scroll the broswer window down a few pixels and then scroll it back up so that the plug-in 
page is exactly where it was before.  Now click in the upper-left corner of the plugin pane.  I still don't 
get 0,0 as I should.  I don't even get 100,100 as I should.  Now I magically get 100,130 (or something 
in that range).  If I now "touch" the window resize box and resize the window by just 1 pixel (anything 
to cause a window refresh), now when I click in the corner I'll get 100,100 again.

So, not only is the GrafPort set to the Window and not the plug-in pane as described in the Gecko spec, 
but even the Window offsets are flucuating randomly.

Comment 4

[Simon Fraser [no longer active]]

I can reproduce this in Camino, certainly.

Comment 5

[Simon Fraser [no longer active]]

Note that NP_Port.portx and NP_Port.porty should always be correct, so you can
use these to fix the port origin:
  SetOrigin(npport->portx, npport->porty);

Comment 6

[Brian Greenstone]

Ah, but the npport->porty *don't* solve the problem entirely.  I put that into my code when I first 
reported this bug since - it partially fixes it, but not entirely.  Two problems:

1.  I've got to special case my code for browsers which I know are returning incorrect mouse coords via 
GlobalToLocal().

2.  Since the GrafPort's settings are causing some random fluctuations in what GlobalToLocal() resolves 
to, this only gives a "ballpark" estimate of the real mouse coordinates.  70% of the time, they're dead 
on, but as I explained in the previous reply, sometimes the Y coordinate will randomly flutter +/- 40 
pixels or so.  So, even though I can offset the global mouse coord by the NP_Port coord, it won't always 
work because I still have to call GlobalToLocal() to get the window coordinates, and that GlobalToLocal() 
call is not reliable due to that ~40 pixel y-coord random flutter.

It seems like the browser is attempting to set that GrafPort correctly, but sometime is going wrong.  If 
the GrafPort were just set to the browsers window then there wouldn't be random flucuations in the y 
coordinate.  But if it were trying to set the GrafPort to the plug-in's coord and just not working right 
then this could be the case.

Comment 7

[Simon Fraser [no longer active]]

Won't calling SetOrigin(npport->portx, npport->porty) just before every call to
GlobalToLocal() work (for all browsers)?

Comment 8

[Brian Greenstone]

Normally, yes.  I think SetOrigin() might work, but that call is still dependant on the current GrafPort 
being correct, and it does not seem to be correct.

Maybe if I force the current GrafPort to the *real* GrafPort of the window (not the one that's being set 
before the Event is called), then SetOrigin might work on that.  If so, then that's a workable work-
around, but it's clear that the current Mozilla build is definitely not following the Gecko rules, so this 
should probably still get fixed so that it matches the Gecko spec so nothing needs to be special-cased

Comment 9

[Simon Fraser [no longer active]]

Oh, are you saying that the GrafPtr is the wrong port? That's bad, and it would
surprise me. Of course the NP_Port contains the correct GrafPtr.

Comment 10

[Brian Greenstone]

Actually, now that you mention it... I have a theory...

I bet the GrafPort is correct, but the origin that's being set before NPP_HandleEvent() is defintitely 
wrong.  I assume Mozillia calls SetOrigin() before calling the event function, but it's not setting the 
correct values.  The Origin is 0,0 most of the time, but as described earlier, there are cases where the y 
coordintes are off by around 40 pixels or so.  In those cases it's like the origin is being set to 0, -40 for 
some reason.  In either case, Mozilla should be setting the origin to the correct coords since that's what 
the Gecko spec says.

I'm going to try something in my code...stay tuned....

Comment 11

[Brian Greenstone]

Yay!  Problem resolved (but it's still a bug).  Yes, by calling SetOrigin() with the NP_Port coords 
everything is good and GlobalToLocal() now returns legitimate values.

However, here's what it says in the Gecko spec on page 69:

"The browser calls SetOrigin(npport->portx, npport->porty).This method makes the instance's upper-
left coordinate equalto(0,0)".

This clearly is not being done.  The Origin is either not being set at all, or it's being set to bogus values 
(I'm guessing the latter).  So, to fix this bug all that needs to be done is to make sure Mozilla is calling 
SetOrigin before it calls the event function.

Comment 12

[Simon Fraser [no longer active]]

Attachment: Patch for carbon and cocoa widget

Comment 13

[Simon Fraser [no longer active]]

We should get this in to fix the Flip4Mac drawing issue.

Comment 14

[Simon Fraser [no longer active]]

Actually, this patch doesn't help (though I think it's doing the right thing).

Comment 15

[Glenn Howes]

The Mac ChemDraw plugin is definitely still seeing this problem. Again, the symptoms are when a plugin using the QuickDraw drawing model tries to track a mouse event, the origin of the QuickDraw port are set to apparently arbitrary coordinates. This behavior is not seen in any version of Safari. In looking through the source it doesn't appear that the fix suggested in comment# 12 (or anything similar) was ever picked up, and it seems as though the code in that area has been restructured somewhat since to make it more emphatically Cocoa based. 

This particular bug is making our plugin unusable for editing on FireFox for Mac, and forcing us to recommend Safari for chemical structure drawing. We have a substantial number of Mac users and we would like them to be able to use the browser of their choice.