Problem with Java Applets in Firefox

[Rene Grothmann]

Sorry, if this has been asked before. It should, because the problem is
very prominent on some applets.

I am developping applets for the net. Those applets use the right mouse
button to drag around things, and to call a popup menu. The problem is
that the mouse up event always gets through to Firefox, which then pops
up its context menu. This is annoying.

Is there any workaround, either in Firefox settings, or better, in the
Java source?

I am using recent Firefox (2.0.0.1) most recent Java (happened under
all recent Java versions), and Windows XP, SP2.

Thanks!

 

[Andrew Thompson]

Rene Grothmann wrote:
....

Is there any workaround, either in Firefox settings, or better, in the
Java source?

How about the 'launch source'? I bet this problem
would disappear, if you launch using web-start.

Andrew T.

 

[Remon van Vliet]

Rene Grothmann wrote:
...

How about the 'launch source'? I bet this problem
would disappear, if you launch using web-start.

Web start usually isn't a viable alternative for applets if the applets are
to be deployed on a website accessible by "average consumers". I agree it's
a much better way to publish java applications though.

As for the question from the original poster, I do not know of a workaround
for this problem.

Remon

 

[Mickey Segal]

I am developping applets for the net. Those applets use the right mouse
button to drag around things, and to call a popup menu. The problem is
that the mouse up event always gets through to Firefox, which then pops
up its context menu. This is annoying.

Is there any workaround, either in Firefox settings, or better, in the
Java source?

I am using recent Firefox (2.0.0.1) most recent Java (happened under
all recent Java versions), and Windows XP, SP2.

Rene and I have gone back and forth on this on mozilla.support.firefox, and
he sees the Firefox right click menu when right-clicking on the applet at
www.segal.org/java/config/ and I don't. I'm also using Firefox 2.0.0.1
under Windows XP SP2; I've tested on three different XP SP2 computers, on
one computer using my regular profile as well as a new profile that had been
set up with Firefox never used.

Clearly there is something different between our configurations, but the
difference is not apparent.

Could others test right clicks in the applet at www.segal.org/java/config/
and report what they see?

 

[Andrew Thompson]

Web start usually isn't a viable alternative for applets if the applets are
to be deployed on a website accessible by "average consumers".

What leads you to that conclusion? It seems to
me more a problem of developers who have no
idea how to use web-start, or what it can provide.

If you put a "click here to see my movies", the
user probably does not care if the movie opens in
another page or a free floating window. In fact,
if they have a preference, it would usually be
for the free floating window (with user configurable
desktop and start menu items & file associations -
automatic update, but still allowing off-line use..
etc.).

There are some (few) applets that simply *cannot*
be (usefully or effectively) launched using web-start.
Most other applets, are better suited to web-start
launch.

Andrew T.

 

[John Ersatznom]

There are some (few) applets that simply *cannot*
be (usefully or effectively) launched using web-start.
Most other applets, are better suited to web-start
launch.

Isn't there a huge difference between embedding an applet normally and
using an application-deployment networked installer? Namely, the latter
is actually installing an *app*, rather than an *applet*, and as such it
has all kinds of unsandboxed access to your stuff that an applet would
lack? I wouldn't like to see the currently fairly clean separation
between "Java that might trash my stuff like any other untrusted
executable" and "Java that's safe" on the Web get blurred or confused
any further than it already is...

 

[Andrew Thompson]

Isn't there a huge difference between embedding an applet normally and
using an application-deployment networked installer?

Are you talking about web-start, specifically? (I am)

...Namely, the latter
is actually installing an *app*, rather than an *applet*, and as such it
has all kinds of unsandboxed access to your stuff that an applet would
lack?

No, it does not. Unlike any old jar file with a main() run
in a standard environment, which can do anything the
OS allows, or an applet which is either sandboxed or has
full permissions, a JWS application (or applet) can have
three levels of privileges.

- none - sandoxed (though it is still possible to use the JNLP
API to provide supervised* access to the file system, and
other resources)
- j2ee-application-client(?) a poorly named security level
that allows some things, but restricts others.
- all-permissions - full access.

The two latter privilege levels are only obtained by
signing the jars, and *requesting* extended permissions
from the end user - note that if the PC/Plug-In set-up
they are using is not configured to allow extended
permissions web-start apps., any permissions the user
attempts to grant, will be ignored.

* When using the web-start API to access system
resources, everything that might compromise security
comes complete with many warnings from the plug-in.

..I wouldn't like to see the currently fairly clean separation
between "Java that might trash my stuff like any other untrusted
executable" and "Java that's safe" on the Web get blurred or confused
any further than it already is...

I could link to examples that demonstrate a number
of features of web-start, but in the meantime..
Please read the web-start docs.

Now.. why did you trim the part where I
commented that the greatest barrier to more
web-start launched projects was ignorance on
the part of developers?

Andrew T.

 

[Oliver Wong]

Rene and I have gone back and forth on this on mozilla.support.firefox,
and he sees the Firefox right click menu when right-clicking on the applet
at www.segal.org/java/config/ and I don't. I'm also using Firefox 2.0.0.1
under Windows XP SP2; I've tested on three different XP SP2 computers, on
one computer using my regular profile as well as a new profile that had
been set up with Firefox never used.

Clearly there is something different between our configurations, but the
difference is not apparent.

Could others test right clicks in the applet at www.segal.org/java/config/
and report what they see?

Might be handy if you told us what is and isn't an applet in that page.

When I right click on "Java is working", no pop up appears. Similarly if
I right click on the text within the blue box. Everywhere else that I tried
right clicking, a pop up menu appears.

- Oliver

 

[Andrew Thompson]

Mickey Segal wrote:
....

Could others test right clicks in the applet at www.segal.org/java/config/
and report what they see?

Sorry, not for FF. I cannot run any Mozilla variants
here (and before anybody gets on my case about
getting a second PC for only $...., rah, rah), do
something useful instead/as well and point *your*
working FF at that page.

Andrew T.

 

[Mickey Segal]

Clearly there is something different between our configurations, but the
difference is not apparent.

Could others test right clicks in the applet at www.segal.org/java/config/
and report what they see?

A post on mozilla.support.firefox suggests the answer is a setting:
Tools > Options > Content > JavaScript Advanced Settings
Allow scripts to:
[ ] Disable or replace context menus

We are awaiting word from the original poster as to whether this was the
problem. The original poster has already confirmed that using another
profile he did not have the problem.

 

[Andrew Thompson]

John Ersatznom wrote:

.....
(big trim)
(shrugs) I wish it were clearer/cleaner - for users and
developers alike.

...but just thought I should point out, that the text I
posted after that, bore almost no relation to a response
to the text quoted above... (silly me)

I could link to examples that demonstrate a number
of features of web-start, but in the meantime..
Please read the web-start docs.

Now.. why did you trim the part where I
commented that the greatest barrier to more
web-start launched projects was ignorance on
the part of developers?

Andrew T.

 

[John Ersatznom]

- none - sandoxed (though it is still possible to use the JNLP
API to provide supervised* access to the file system, and
other resources)
- j2ee-application-client(?) a poorly named security level
that allows some things, but restricts others.
- all-permissions - full access.

The two latter privilege levels are only obtained by
signing the jars, and *requesting* extended permissions
from the end user

Oh, goody. It sounded like there was now a way a site could deploy an
"applet" with automatic, full privileges without user notification,
which would be a big problem (even if they could use JWS to deploy one
with a sandbox too, since sooner or later someone wouldn't).

So nothing obtained from JWS can act "like an app, not an applet" until
specifically authorized by the user then?

 

[John Ersatznom]

Clearly there is something different between our configurations, but the
difference is not apparent.

Could others test right clicks in the applet at www.segal.org/java/config/
and report what they see?

A post on mozilla.support.firefox suggests the answer is a setting:
Tools > Options > Content > JavaScript Advanced Settings
Allow scripts to:
[ ] Disable or replace context menus

We are awaiting word from the original poster as to whether this was the
problem. The original poster has already confirmed that using another
profile he did not have the problem.

Lovely. And we Java programmers still wonder why people continue to
confuse Java and Javash^Hcript.

 

[Rene Grothmann]

[x] Disable or replace context menus

solves the problem.

Somewhat strange, however, since Javascript IS NOT Java, but anyway.
Thanks a lot.

 

[Oliver Wong]

So nothing obtained from JWS can act "like an app, not an applet" until
specifically authorized by the user then?

Correct, barring bugs in the implementation.

- Oliver

 

[Rene Grothmann]

As much as I know, Java Web Start is mostly like an applet nowadays,
besides the fact, that it is not using space on the web page. Both can
used signed jars. The user will be asked in both cases to trust or not
trust the signature. In case, he trusts, the applet or web start
application can access the local computer and make internet
connections. Otherwise, only internet connections to the calling server
are allowed. Another difference is that the external program javaws
caches the applet archive, not the browser. Java Web Start can also
create icons, and it is a very nice way to deliver applocations and
keep them up to date, as intended by Sun's thin client philosophy.

 

[John Ersatznom]

As much as I know, Java Web Start is mostly like an applet nowadays,
besides the fact, that it is not using space on the web page. Both can
used signed jars. The user will be asked in both cases to trust or not
trust the signature. In case, he trusts, the applet or web start
application can access the local computer and make internet
connections. Otherwise, only internet connections to the calling server
are allowed. Another difference is that the external program javaws
caches the applet archive, not the browser. Java Web Start can also
create icons, and it is a very nice way to deliver applocations and
keep them up to date, as intended by Sun's thin client philosophy.

Thin client philosophy, encapsulated:

User .oO "Ha! No matter where I am I can access my data on the go!"
Big corp .oO "Ha! All their data are belong to us! We can hold it
hostage and shake them down anytime our stock is performing poorly!"

 

[Tor Iver Wilhelmsen]

Thin client philosophy, encapsulated:

User .oO "Ha! No matter where I am I can access my data on the go!"
Big corp .oO "Ha! All their data are belong to us! We can hold it
hostage and shake them down anytime our stock is performing poorly!"

Hehe. Yes, that's the reason Microsoft Passport largely failed.
"Hello, dear Oracle, would you like us to hold your customers' data
for you? I assure you we would not want to abuse the information about
license purchases to try and sell SQL Server licenses with an
advantage."