Runtime.exec for launching browser windows: location-independent?

M

Mickey Segal

As the "pure Java" way of launching new browser windows, the showDocument
method, is rendered nonfunctional in more and more environments by popup
blockers, developers whose Java applets are digitally-signed have been able
to get the same functionality by using Runtime.exec calls.

On the Macintosh one can open a new Firefox window regardless of the
location of Firefox as follows:

Runtime.getRuntime().exec(new String[] {"open", "-a", "Firefox.app",
url.toString()});

On Windows it is possible to launch Internet Explorer or Firefox by assuming
a particular location as follows:

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

The problem is that these forms depend on the browser files being in their
usual locations. Is there a way of launching the browsers in a
location-independent way using Java code on Windows, by analogy to what
works on the Macintosh even if Firefox is not in its usual location in the
/Applications folder?


NOTE: We use new browser windows to display further information on outside
Web sites such as articles about a diagnosis being considered by the user.
Using a new browser window allows us to do so without destroying our applet
or trying to shoehorn someone else's Web page into a frame on the same page
as our applet.
 
T

Thomas Fritsch

Mickey said:
As the "pure Java" way of launching new browser windows, the showDocument
method, is rendered nonfunctional in more and more environments by popup
blockers, developers whose Java applets are digitally-signed have been able
to get the same functionality by using Runtime.exec calls.
I assume you are talking about showDocument(URL) of class Applet here.

[...]
NOTE: We use new browser windows to display further information on outside
Web sites such as articles about a diagnosis being considered by the user.
Using a new browser window allows us to do so without destroying our applet
or trying to shoehorn someone else's Web page into a frame on the same page
as our applet.

showDocument(URL) of JavaWebStart should be more powerful/flexible than
its Applet counterpart. Other posters probably have more experience
about it than me. See also
<http://java.sun.com/products/javawe.../BasicService.html#showDocument(java.net.URL)>

In a WebStart application it is used like this:
import javax.jnlp.*;

BasicService basicService = (BasicService)
ServiceManager.lookup("javax.jnlp.BasicService");
basicService.showDocument(url);

Of course, this approach would require you to move your design from
browser-ebedded applet to free-standing WebStart-application.
 
M

Mickey Segal

Thomas Fritsch said:
Of course, this approach would require you to move your design from
browser-ebedded applet to free-standing WebStart-application.

That may be a good long-term solution but it will not work with the
environment constraints on many of our users.

One person suggested that the Windows "start" command is pretty much
equivalent to the Macintosh "open" command. Does anyone know the syntax?

I've also tried:
Runtime.getRuntime().exec("rundll32 url.dll,FileProtocolHandler " + url);
This opens the default browser, but unfortunately when it is run from the
Web in Internet Explorer as the default browser it opens the applet in the
same window, destroying the applet.
 
S

Steve W. Jackson

Mickey Segal said:
As the "pure Java" way of launching new browser windows, the showDocument
method, is rendered nonfunctional in more and more environments by popup
blockers, developers whose Java applets are digitally-signed have been able
to get the same functionality by using Runtime.exec calls.

On the Macintosh one can open a new Firefox window regardless of the
location of Firefox as follows:

Runtime.getRuntime().exec(new String[] {"open", "-a", "Firefox.app",
url.toString()});

On Windows it is possible to launch Internet Explorer or Firefox by assuming
a particular location as follows:

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

The problem is that these forms depend on the browser files being in their
usual locations. Is there a way of launching the browsers in a
location-independent way using Java code on Windows, by analogy to what
works on the Macintosh even if Firefox is not in its usual location in the
/Applications folder?


NOTE: We use new browser windows to display further information on outside
Web sites such as articles about a diagnosis being considered by the user.
Using a new browser window allows us to do so without destroying our applet
or trying to shoehorn someone else's Web page into a frame on the same page
as our applet.

On a Mac, you can omit the "-a" switch to the "open" command and allow
the system to use the preferred browser. By default, that's Safari on
all recent systems, but it can of course be changed. I have mine set
for Firefox, and it's in a non-standard location, but that approach
works perfectly in my testing. It also works for files, provided the
system has a setting for the application to handle the file.

On Windows systems beyond 98 (we dropped support in our app for 98 and
earlier, including NT), you can use "cmd start url" to hand off the URL
to the designated default browser. The same approach seems to work for
files if there's an association for them. I believe I recall that it
resulted in prompting when no associated application was found (and
perhaps for Mac OS X as well). I haven't tried in Windows 98, but the
"cmd.exe" used to be "command.com" and may well work there too. Aside
from renaming the command interpreter, I don't know how much else has
changed down deep.

Even on Linux, I found that an approach could be used that depends on
information about the desktop environment being used. That's more
tricky to do, but it's clearly possible since any given environment
(like KDE, Gnome, etc.) has some kind of file manager program that can
show files and allow one to be opened with a designated application.

= Steve =
 
S

Steve W. Jackson

Mickey Segal said:
That may be a good long-term solution but it will not work with the
environment constraints on many of our users.

One person suggested that the Windows "start" command is pretty much
equivalent to the Macintosh "open" command. Does anyone know the syntax?

I've also tried:
Runtime.getRuntime().exec("rundll32 url.dll,FileProtocolHandler " + url);
This opens the default browser, but unfortunately when it is run from the
Web in Internet Explorer as the default browser it opens the applet in the
same window, destroying the applet.

What I used for Windows and the "start" command was simply a URL. If
it's a file, I made it a file URL. So whatever type of URL I used, I
ended up with "cmd start URL" being passed to exec().

I temporarily switched my XP system to IE as default and tested it. The
behavior you describe where it replaces the current page is but one of
many reasons I thoroughly despise IE. If not for the fact that my
company (like so many others) insists on forcing me to use resources
that ONLY work with IE on Windows, I'd never touch it.

= Steve =
 
M

Mickey Segal

Steve W. Jackson said:
On Windows systems beyond 98 (we dropped support in our app for 98 and
earlier, including NT), you can use "cmd start url" to hand off the URL
to the designated default browser. The same approach seems to work for
files if there's an association for them. I believe I recall that it
resulted in prompting when no associated application was found (and
perhaps for Mac OS X as well). I haven't tried in Windows 98, but the
"cmd.exe" used to be "command.com" and may well work there too. Aside
from renaming the command interpreter, I don't know how much else has
changed down deep.

The following seem to work both locally and from the Web using Windows XP:

From Internet Explorer:
Runtime.getRuntime().exec("iexplore.exe " + url);

From Firefox 1.5:
Runtime.getRuntime().exec("firefox.exe \"" + url + "\"");
(note the quotes around the URL)

This seems like a clean approach. Does it fail somewhere I haven't noticed
(I haven't tried Windows 98 yet)?
 
S

Steve W. Jackson

Mickey Segal said:
The following seem to work both locally and from the Web using Windows XP:

From Internet Explorer:
Runtime.getRuntime().exec("iexplore.exe " + url);

From Firefox 1.5:
Runtime.getRuntime().exec("firefox.exe \"" + url + "\"");
(note the quotes around the URL)

This seems like a clean approach. Does it fail somewhere I haven't noticed
(I haven't tried Windows 98 yet)?

I'm assuming it relies on some mechanism I can't see to locate the exe
file. It doesn't work in a command prompt window on my XP system. But
if it appears to work from Java code, I guess that's not so relevant.
Of course, there's the fact that only Firefox and IE are covered,
whereas those who use Netscape, Mozilla or other browsers aren't.

= Steve =
 
M

Mickey Segal

Steve W. Jackson said:
I'm assuming it relies on some mechanism I can't see to locate the exe
file. It doesn't work in a command prompt window on my XP system. But
if it appears to work from Java code, I guess that's not so relevant.
Of course, there's the fact that only Firefox and IE are covered,
whereas those who use Netscape, Mozilla or other browsers aren't.

It seems to work on Windows 98 too.

Presumably the approach could be extended to other browsers as well. What
we currently do is check for the following browsers:
1. Windows Firefox
2. Windows Internet Explorer
3. Macintosh Firefox

and use the appropriate Runtime.exec call. For all others we use
showDocument. In the case of Macintosh Safari showDocument still works. I
haven't tested Netscape or Mozilla recently.
 
O

Oliver Wong

Steve W. Jackson said:
I'm assuming it relies on some mechanism I can't see to locate the exe
file. It doesn't work in a command prompt window on my XP system. But
if it appears to work from Java code, I guess that's not so relevant.
Of course, there's the fact that only Firefox and IE are covered,
whereas those who use Netscape, Mozilla or other browsers aren't.

I'd assume it depends on those executables appearing on the System PATH.

- Oliver
 
S

Steve W. Jackson

Oliver Wong said:
I'd assume it depends on those executables appearing on the System PATH.

- Oliver

That's why I tested it in a Command Prompt under XP. But it failed
precisely because neither of the two browsers he named are in my PATH.
So I figured there must be something else at work from within Java.

= Steve =
 
M

Mickey Segal

To sum up, here is a working version of the code for applications and signed
applets (microsoftBrowser, firefoxBrowser, windowsOS and macOS are booleans
set elsewhere in the code based on information derived from the browser or
Java properties):

final static void showInBrowser(URL url)
{
try
{
if (microsoftBrowser && windowsOS)
Runtime.getRuntime().exec("iexplore.exe " + url);
else if (firefoxBrowser && windowsOS)
Runtime.getRuntime().exec("firefox.exe \"" + url + "\"");
else if (firefoxBrowser && macOS) Runtime.getRuntime().exec(new String[]
{"open", "-a", "Firefox.app", url.toString()});
else appletContext.showDocument(url, "_blank");
}
catch (Exception e)
{
System.out.println("Couldn't show in browser: " + e);
}
}

It doesn't cover certain browser/OS versions, but they get showDocument
until special code for them is added.

If there are problems with this approach other than the impurity of treating
browsers differently or the audacity to want showDocument functionality in a
signed applet I'd be interested in hearing about the problems.

If there are improvements or additions for other browser/OS combinations it
would be good to hear about them. (No special code seems necessary for
Safari on the Macintosh since it allows showDocument.)
 
A

Andrew Thompson

Roedy said:
I gather it would use HotJava for rendering?

Why? *

a) HotJava is virtually useless for real world (wide web) HTML.
b) The method mentions "This will typically replace the page
currently being viewed in a browser..". I imagine they could be
more definitive if the browser component was HotJava.

And as a follow-up to both this and my own question
(next thread up 'BrowserLauncher - JWS example') of..
'Has anybody used this successfully?'

Tests here running with the 1.5.0-beta JRE keep throwing ..
javax.jnlp.UnavailableServiceException: uninitialized

I'll keep working on it, but if anyone here can tell me
how to initialise that dang service, or cause it to be
initialised, please speak up.

* If it did, I would consider the method to be essentially useless.
 
A

Andrew Thompson

Yes, in that it seems to work[1].
No, in that the programmer cannot specify a frame or window name
(..and that is probably A Good Thing).

No[1]. On my system (running 1.5.0-beta, on Win XP Pro),
it opens Mozilla 1.7.2 - my default browser (currently).

[1] Here are the examples I am using ..
<http://www.physci.org/browserlauncher/jnlp/>
there is both an application and applet.

How well does this work for other people?
Does it
- steal an existing window?
- open a new browser, or browser-tab?
- do nothing at all?
( What browser/Java/OS as well, please )

Mickey, it occured to me that if you use WebStart to launch your
applets, they can not only have access to a more reliable 'show
a page' functionality, but also have the advantage that the applet
becomes independent of the original HTML page (the user can navigate
from it, but the applet stays on-screen).

Of course, once you go WebStart, the temptation is to break
out of applets entirely and create an application, but applets
are supported (to some extent*) within JWS.

* No JS interaction, but it seems that most of your
JS is simply to work around the unpredictable effects
of browsers in any case, so it should become unnecessary
in the JWS version..

Follow-up note.

My earlier attempts to use JWS services were failing because
I was attempting it from a non-JWS application, and the
ServiceManagerStub had not been created or set.

I am not sure if there is a way to do that yourself, but
have not investigated it much yet. Experiences at creating
an Applet stub suggest to me it is not trivial.
 
M

Mickey Segal

Andrew Thompson said:
Mickey, it occured to me that if you use WebStart to launch your
applets, they can not only have access to a more reliable 'show
a page' functionality, but also have the advantage that the applet
becomes independent of the original HTML page (the user can navigate
from it, but the applet stays on-screen).

Our typical user is loading our software from the hospital network computer
that happens to be nearest to them at the moment. They are reluctant to
(and discouraged from) doing anything that seems like a software
installation. The launching code I posted in response to one of Steve
Jackson's messages in this thread seems to be doing what we want so I am
inclined to keep with this approach as long as it works.

BTW Andrew, why are you using 1.5.0-beta instead of 1.5.0_06 or 1.6.0-rc?
We have converted to 1.6.0-rc because of its fix to the HotSpot crash
problem (www.segal.org/java/sun_jit/).
 
A

Andrew Thompson

Mickey Segal wrote:
(snip - makes sense)
...
BTW Andrew, why are you using 1.5.0-beta instead of 1.5.0_06 or 1.6.0-rc?

Because I'm evil? No ..wait, because I'm lax and more
than a little stupid? Yep - that sounds more like it.

Must update - Real Soon Now.

In fact, I'm sure I have at least _04 about here somewhere..
why the heck is the browser using -beta? (wanders off, ..muttering)
 
R

Roedy Green

When you run an Applet with JAWS, what is it running in? Does that
think support showDocument? If yes, what else does Sun have that can
run an Applet and make a feeble attempt at rendering HTML.
 
A

Andrew Thompson

Roedy said:
When you run an Applet with JAWS, what is it running in?

AppletViewer. At least, it looks like AppletViewer to me.
...Does that
think support showDocument?
No.

..If yes, what else does Sun have that can
run an Applet and make a feeble attempt at rendering HTML.

AppletViewer makes no attempt to render any HTML.

The 'document base' required by the JNLP applet-desc
element is simply to provide a documentBase() if it is
requested by the applet.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top