AppletContext.showdocument() vs. popup-blockers

[Mickey Segal]

I did some testing and it looks like the Google pop-up blocker does not
block mailto but the Microsoft XP SP2 popup blocker does block mailto. So
it seems one needs a getRuntime approach to deal with the mailto, but I
don't know the syntax of the Windows call.

 

[Chris Berg]

One soluton could be to open a normal HTML page, using the technique
we've discussed, which could get the mail address as part of the URL,
like "http://domain/[email protected]". The page should
contain a clickable link saying "Send e-mail", which would launch the
mailto:[email protected] url - the mail address extracted from the
url by some JavaScript. A bit clumsy, yes, but it would work, i guess.
And you could design the HTML page to be a "Do you really want to send
a mail" - style dialog.

Anyway, this whole issue is indeed very difficult; each time you start
to interact with the native OS from an Applet, you get lost in the
swamp of different versions etc. I guess there are thousands of
combinations of OS/VM/browser/mailclient, and if you aim at a
production version, you must, ideally, test each and every one of the
combinations on a separate computer. (I shudder to think of it - just
consider the electricity bill !! ).


Chris

 

[Mickey Segal]

When you do:
getAppletContext().showDocument(new URL("mailto:<[email protected]>"));
from Internet Explorer on Windows which e-mail program gets launched? Is it
a Microsoft e-mail program or whatever is set as your default Windows e-mail
program? Is there some code one can execute similar to:
Runtime.getRuntime().exec("explorer "+url);
that will call up the same e-mail program that showDocument would call up?

 

[Andrew Thompson]

I feel that I must correct one misunderstanding here. My intention is
NOT to annoy users with popups that get past popup-blockers.

I am maintaining an signed, interactive applet where the user clicks a
button saying '"Open file in a new window" (or something similar -
it's not in english), and it has always worked before the
popup-blockers got popular.

*That* is completely different! I wished you had mentioned earlier
that you had the complete knowledge and active co-operation of the
user. Being able to ask the user to click a button if the new window
fails to appear pretty much completely solves the problem.

For any of the more complicated situations, Mickey is probably the best
to advise, he has 'been there - done that'. I'll leave him to it.

 

[Andrew Thompson]

On Thu, 13 Jan 2005 16:09:28 -0500, Mickey Segal wrote:

(Me haranguing the OP over attempting
to 'force' pop-ups on users)

Don't take it personally.

Good advice Mickey.

...I got the same reaction a few months ago when I
brought up the same issues, ...

Yep (grins). I remember *that* thread. It was a classic.

.., despite explaining that we use a signed applet.

No matter how *many* times you mentioned that you had the users
active support, it often drifted back to those same responses
(like I was giving earlier). ;-)

 

[Chris Berg]

user. Being able to ask the user to click a button if the new window
fails to appear pretty much completely solves the problem.

Well, this is not a good option, at least not for us.

The user clicks something to open the new window (in our applet it's
not a standard component, but no reason to go into detail about that
here - it IS a mouse-click). If I could have my way the Applet would
get some sort of feed-back saying that the action had been blocked, so
I could tell my user how to fix it. Of course, pop-up blockers don't
signal anything, it would make it too easy for the adware to take
action against the user. So, i'm left with having to ALWAYS display a
long essay about the problem to the user. And it's not simple to
explain to a novice how to turn off the XP-SP2 blocker for a
particular domain. In his own (possibly non-english) language, that
is!

Anyway, the problem is apparently solved now. I can open a file or a
link in a new window without annoying any blocker, by first using JS
to detect if I'm running on Win+IE, and if so use System.exec(), which
is, of course, only an option in a signed applet.


Chris

 

[Mickey Segal]

Chris is right that you don't want to have "if this fails click here" type
of workarounds. The functionality that Chris is trying to provide sounds
similar to our situation in which we allow a user of our applet to pop up an
HTML page from the Web site of a scientific journal to provide more details
about the evidence behind cited.

Chris' getRuntime workaround seems to work fine for those of us whose
applets need to be signed anyway, but both Chris and I were also using
showDocument to pop up new e-mail message windows. I suppose one could pop
up new Web pages (using a servlet or local file writing) with mailto URLs or
use a servlet to send the e-mail, but it would be simpler to know the syntax
for using Runtime.exec for bringing up the e-mail program and there would be
advantages in that the user would know a traditional e-mail was sent.

 

[Mickey Segal]

Runtime.getRuntime().exec("explorer "+url);

I'm puzzled by the use of "explorer". Internet Explorer is named iexplore
so what is being invoked with the explore command?

I see in the BrowserControl code at
http://www.javaworld.com/javaworld/javatips/jw-javatip66.html that you can
also invoke a browser using rundll32 syntax:

Runtime.getRuntime().exec('rundll32 url.dll,FileProtocolHandler
http://segal.org);

and I found that one can use this to invoke an e-mail window using syntax
such as:

Runtime.getRuntime().exec('rundll32 url.dll,FileProtocolHandler
mailto:[email protected]);

How do you figure out whether to use explore, iexplore or the rundll32
approach? Presumably each approach is somewhat different, possibly relating
to particular programs versus default programs. Similarly are there three
possible syntaxes one can use for invoking e-mail programs and what does
each do?

Even before figuring out these details it seems clear that we have made some
progress in that we now have one way of popping up a window with a new
e-mail message using Runtime.exec.

 

[Mickey Segal]

Further testing shows that the following two approaches to launching an
e-mail window:

showDocument(mailto:[email protected]);
and
Runtime.getRuntime().exec('rundll32 url.dll,FileProtocolHandler
mailto:[email protected]);

launch the default e-mail program, which seems like the desired result.
Since the showDocument approach for e-mail is blocked by the Microsoft XP
SP2 popup blocker the Runtime.exec approach seems workable for those of us
using signed applets who don't want to make users go through the bother of
turning off popup blockers for our sites (they have already accepted our
digital certificates to make the applets signed to enable other
functionality).

If there are better Runtime.exec parameters to use it would be good to know
about it. Apparently there are some limitations on using the url.dll
approach for Web pages ending in htm or html, but that is not evident of
Windows XP.

 

[Real Gagnon]

If there are better Runtime.exec parameters to use it would be good to

know about it. Apparently there are some limitations on using the
url.dll approach for Web pages ending in htm or html, but that is not
evident of Windows XP.

You can do many things with the rundll32 utility, see
http://www.rgagnon.com/pbdetails/pb-0204.html
for a quick list.

If you have problem opening an HTM file, try to replace the last character:
rundll32 url.dll,FileProtocolHandler http://www.rgagnon.com/page.htm
for
rundll32 url.dll,FileProtocolHandler http://www.rgagnon.com/page.htm

Bye.

 

[Mickey Segal]

The Runtime.exec approach seems to work fine on Windows XP but testing on
Windows 98 shows problems. Both

Runtime.getRuntime().exec("rundll32 url.dll,FileProtocolHandler " + url);
and
Runtime.getRuntime().exec("explore " + url);

fail to launch a new browser window if the URL ends in .html. Also, for
URLs that work, the current instance of the browser window is used,
destroying the java applet.

For a mailto URL the e-mail program simply fails to appear. So it seems
that this approach does not work on Windows 98, but it does seem to work on
Windows XP. This limits the usefulness of this workaround unless you are
sure that all Windows users have Windows XP or implement yet another layer
of environment testing.

 

[Mickey Segal]

If you have problem opening an HTM file, try to replace the last
character:
rundll32 url.dll,FileProtocolHandler http://www.rgagnon.com/page.htm
for
rundll32 url.dll,FileProtocolHandler http://www.rgagnon.com/page.htm

I could try that but it seems there is a bigger problem on Windows 98: the
URL opens in the same browser window, destroying the applet.

 

[Mickey Segal]

I could try that but it seems there is a bigger problem on Windows 98: the
URL opens in the same browser window, destroying the applet.

An alternate strategy of using:

Runtime.getRuntime().exec("\"C:\\Program Files\\Internet
Explorer\\IEXPLORE.EXE\" " + url);

seems to work for Web pages, even on Windows 98, opening a new page without
destroying the applet.

In contrast to my earlier post, the e-mail program is now coming up fine on
Windows 98 using code:

Runtime.getRuntime().exec("rundll32 url.dll,FileProtocolHandler " +
mailString);

So this may be a robust approach for those of us wishing to pop up Web pages
and e-mail windows from signed applets.

If there is something I'm overlooking I'd appreciate hearing about it from
people on this newsgroup before hearing about it from users.

 

[Real Gagnon]

An alternate strategy of using:

Runtime.getRuntime().exec("\"C:\\Program Files\\Internet
Explorer\\IEXPLORE.EXE\" " + url);

seems to work for Web pages, even on Windows 98, opening a new page
without destroying the applet.

Another way is :

cmd /c start <url> (NT or better)

start <url> (Win9x)

Works with http or mailto protocol.

Bye.

 

[Andrew Thompson]

....
In contrast to my earlier post, the e-mail program is now coming up fine on
Windows 98 using code:

Runtime.getRuntime().exec("rundll32 url.dll,FileProtocolHandler " +
mailString);

So this may be a robust approach for those of us wishing to pop up Web pages
and e-mail windows from signed applets.

If there is something I'm overlooking I'd appreciate hearing about it from
people on this newsgroup before hearing about it from users.

I do not think this will apply to your user base, but is relevant
for anybody attempting to produce the default email client in a
wider internet based context.

If a user is surfing to the (signed) applet from an internet cafe,
or the browsers at college or the library, there will probably not
be a 'default email client'. It can also cause minor problems in
the event that the user is visiting the applet from someone elses
PC - the default email client that pops up is not their own and they
may not even think before typing a quick message and clicking 'send'.

Something I am not clear on yet, though Mickey.
Have you perused the source of BrowserLauncher? There are
lots of tips and comments in the source that might be helpful.

(Though I'm not sure - I have not checked the links in this
thread closely and some of them might come back to
'BrowserLauncher' under a different name).

The basic source of BrowserLauncher (one line is altered,
commented) is here..
<http://www.physci.org/codes/display.jsp?fl=/edu/stanford/ejalbert/BrowserLauncher.java>

HTH

 

[Mickey Segal]

If a user is surfing to the (signed) applet from an internet cafe,
or the browsers at college or the library, there will probably not
be a 'default email client'. It can also cause minor problems in
the event that the user is visiting the applet from someone elses
PC - the default email client that pops up is not their own and they
may not even think before typing a quick message and clicking 'send'.

We may switch to an approach that does not require an e-mail client for such
reasons, but for now we are using e-mail clients.

Something I am not clear on yet, though Mickey.
Have you perused the source of BrowserLauncher? There are
lots of tips and comments in the source that might be helpful.

(Though I'm not sure - I have not checked the links in this
thread closely and some of them might come back to
'BrowserLauncher' under a different name).

The basic source of BrowserLauncher (one line is altered,
commented) is here..
<http://www.physci.org/codes/display.jsp?fl=/edu/stanford/ejalbert/BrowserLauncher.java>

Your mention of BrowserLauncher was one of the keys to solving the problem.
I had found the original JavaWorld article
(http://www.javaworld.com/javaworld/javatips/jw-javatip66.html) referenced
in the code you posted. The particular forms of the Windows parameters have
varied over the years since BrowserLauncher was written and another URL I
found helpful in testing forms of the Runtime.exec calls was
http://www.jsiinc.com/SUBI/tip4100/rh4162.htm.