Closed Bug 645846 Opened 13 years ago Closed 11 years ago

getLocationOnScreen returns wrong coordinates in Firefox 4/Mac

Categories

(Plugins Graveyard :: Java (Apple), defect)

Product:
Plugins Graveyard
Component:
Java (Apple)
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: haysmark, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15 ( .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0

Starting with Firefox 4.0 on Mac, the applet method getLocationOnScreen() (inherited from Component?) only returns the left/top set on the applet's style, which is no where close to its true screen position. This does not affect Safari 5 or Firefox 3.6 on the same Mac, nor does it affect Firefox 4.0 on Windows XP (32 bit).

Reproducible: Always

Steps to Reproduce:
1. Load the provided URL
2. Accept the trusted applet
3. Observe where the mouse moves and clicks
Actual Results:  
The Java Console reports that the "Document root" is at (0,22). The mouse moves to (0,22) on your desktop and clicks, potentially closing the Firefox window if you have it maximized.

Expected Results:  
The Java Console reports that the "Document root" is at some other value. The mouse should move to approximately the top-left of the document, click, then move the mouse over a text field and type "again."
Moving to plugins, where other Java issues are located. As of Firefox 13 with Java 1.6.0 u31, getLocationOnScreen is still broken.

I noticed that if you hold down command+shift and wave your mouse around, the applet appears in the top left of the screen, when it should appear where the applet is; this seems like an uncanny coincidence.
Component: Java to XPCOM Bridge → Plug-ins
I am experiencing the same problem on Java early access 7u40. Though this is not a problem on Safari.
I'm on:
User Agent - Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Firefox/21.0
Any news on getting this fixed? I'm running Firefox 21.0 on Mac.
This might be due to Java calling NPN_ConvertPoint() from a non-main thread.
When running this in Nightly from the terminal, does it print the warning:
> "Not running on the plugin's main thread!"
... multiple times?
We tested with 24.0a1 but no such message comes in the console.

Basically the Java applet invokes a popup menu to show relative to the parent component:

javax.swing.JPopupMenu.show(Component, int, int)

and this code uses a method like "parentComponent.getLocationOnScreen()" which eventually translates in a call to the peer which probably should delegate eventually to the web browser to see at which coordinates the applet was placed in the page.
Sorry, i just checked and noticed that you don't get that message in our Nightly builds.

However, i get them constantly with a debug build and the referenced URL - Java tries to NPN_ConvertPoint() {0,0} from NPCoordinateSpacePlugin to NPCoordinateSpaceFlippedScreen from a thread other then the main plugin thread, which we make fail. 

This example also crashes plugin-container due to an off-main-thread NPN_Release() when trying to reload after the applet loaded.
Assignee: jhpedemonte → nobody
Status: UNCONFIRMED → NEW
Component: Plug-ins → Java (Apple)
Ever confirmed: true
Product: Core → Plugins
Version: unspecified → 7.x
We're not going to track this. If you want it fixed, you need to file a support ticket with Oracle.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INCOMPLETE
I do not quite agree with this, the same applet code works fine with Safari on Mac.
How about if I prepare a simple applet on a test web site, give you guys a link and you add some logging on the Firefox side?
Someone already created a website showing this:
http://dreamchain.com/static/applet-with-menubar.html

It shows the menu popup appearing in the top left on JDK7u40 on Mac 10.8.
(In reply to Radu Coravu from comment #8)
> I do not quite agree with this, the same applet code works fine with Safari
> on Mac.

They probably tolerate NPN_ConvertPoint() being called from another thread.
If i just return some coordinates >{0,0} from that function if it's being called from a non-main-thread, the popups in the test-cases move around, so that is the problem.
So what should we do now? 
I am not familiar how the Firefox API connects to its plugins.
Probably the  NPN_ConvertPoint() is implemented on the Firefox libraries side, right? If so, this bug should probably be reopened.
If not, a bug should be added on the Oracle side.
(In reply to Radu Coravu from comment #11)
> Probably the  NPN_ConvertPoint() is implemented on the Firefox libraries
> side, right? If so, this bug should probably be reopened.
> If not, a bug should be added on the Oracle side.

Please file a bug with Oracle:
NPN_ConvertPoint() is implemented on Firefox' side. Java however calls it from a thread other than the main plugin thread, which is incorrect.
I hope I don't bother you too much, I just need to understand this (you can stop answering me if you want :)).

A java application (applets as well) can have a number of threads inside it. 
When you talk about "main plugin thread" do you mean the main Java thread on which the applet was loaded (the thread which called its "start()" method)?
Or do you mean a native Firefox thread which connects to the applet?

Usually when the user clicks various buttons, menus, etc in a Java application all events are sent using the AWT thread (and not the thread which initially loaded the applet). This is the regular behavior in a Java application.

Why would this issue only occur on Mac?
Could the "NPN_ConvertPoint" be modified so that when it is called from an improper thread it could invoke its code on the proper thread and thus return the proper result?
I mean the native thread on which the Java plugin is getting calls from Firefox and should be calling back into it.
I don't know if Java should automatically take care of doing those calls on the right native thread when you trigger them from a Java thread - i guess Oracle can answer that best.

This function is only supported (and needed) on OS X and addressing thread-safety is out of scope for us here.
(In reply to Georg Fritzsche [:gfritzsche] from comment #14)
> I mean the native thread on which the Java plugin is getting calls from
> Firefox and should be calling back into it.
> I don't know if Java should automatically take care of doing those calls on
> the right native thread when you trigger them from a Java thread - i guess
> Oracle can answer that best.
> 
> This function is only supported (and needed) on OS X and addressing
> thread-safety is out of scope for us here.

Thanks for getting back to me on this issue. This is really interesting discussion. I'd like to try to rephrase Radu's question: is there a known Java thread that is guaranteed to use the main native thread? I'm wondering if there is a way to make the getLocationOnScreen call from that Java thread as a workaround.

Sadly we are not on the best terms with Oracle so opening a ticket with them is out of the question.
A bug against the Java Plugin is filed - we are looking into it.
Hi Thomas,

Do you have a bug ID for this?

Regards,
Radu
JDK-8016489: [macosx] FireFox: NPN_ConvertPoint is not being called on plugin main thread
Thank you Thomas.
Resolution: INCOMPLETE → INVALID
Product: Plugins → Plugins Graveyard
You need to log in before you can comment on or make changes to this bug.