AppletContext.showdocument() vs. popup-blockers

[Chris Berg]

java.applet.AppletContext.showDocument(URL,String) seems to be blocked
by pop-up blockers in IE (XP-SP2, Google toolbar, MSN Toolbar), even
if the applet is signed. I haven't tested Mozilla, but I assume it's
the same.

There is apparently no significant indication to the user that
something has been blocked, so he/she assumes the function doesn't
work. And the applet gets no information about the blockage. Or does
it?

Any ideas how to get around this?

Chris

 

[Andrew Thompson]

java.applet.AppletContext.showDocument(URL,String) seems to be blocked
by pop-up blockers in IE (XP-SP2, Google toolbar, MSN Toolbar),

Does it? It is news to me, and I am aware of the changes wrought
by SP2 that now cause JS pop-ups to fail. All information I have seen
thus far suggests it left Java applets as functional (or dysfunctional,
as the case may be) as they were.

For further details on showDoc (never reliable) and test page..

Any ideas how to get around this?

Use a CardLayout, or a Dialog.

 

[Andrew Thompson]

Does it? It is news to me, ..

Wait a second now! My memory is terrible. :-(

The only post on IE w/SP2 worth mentioning..
<http://groups.google.com.au/[email protected]>

 

[Mickey Segal]

java.applet.AppletContext.showDocument(URL,String) seems to be blocked
by pop-up blockers in IE (XP-SP2, Google toolbar, MSN Toolbar), even
if the applet is signed. I haven't tested Mozilla, but I assume it's
the same.

There is apparently no significant indication to the user that
something has been blocked, so he/she assumes the function doesn't
work. And the applet gets no information about the blockage. Or does
it?

At www.segal.org/java/ in the "Pop-up blockers in Internet Explorer for
Windows stop Java showDocument" section there are 4 web pages illustrating
this issue and a fifth page with a strategy for detecting blockers.

The Netscape/Firefox and Apple popup blockers use a different approach and
do not block showDocument.

The only workarounds I am aware of are:
1. Convert all your documentation or referred content from HTML pages to
other forms (often impractical, particularly when linking to content of
others).
2. Offer advice on enabling popups for your site, least obtrusively if
coupled with popup-blocker detection in Internet Explorer on Windows.
3. Get users to switch away from Internet Explorer on Windows.

I agree that it is odd that a signed applet should be restricted in use of
popups, but the procedures for signed applets and for popup blockers were
not thought out in a coordinated way that would deal with this overlap in a
sensible fashion.

 

[Chris Berg]

HEUREKA!

I found a way around it (I think):

public void showDocument(URL url) {

// do exec("explorer "+url) if it's windows
// should also check for browser, but how?
// if exec() fails, we roll back to showDoc.

if (System.getProperty("os.name").indexOf("Windows") >=0){
try{
Runtime.getRuntime().exec("explorer "+url);
return;
}catch(Exception e){}
}else{
getAppletContext().showDocument(url);
}
}

It seems to work on XP - don't know about Win98, but who really cares
any more?

The applet has to be signed, of course, otherwise exec() is banned.

Only trouble is, on Firefox, it will open the new url in IE, which, of
course, we don't want. So, how do I find out if I'm running on IE?
It's not enough to ask for System.getProperty("java.vendor"), because
about half of IE users run the Sun VM.

Any suggestions?

Chris

 

[Chris Berg]

More: also found a way to determine if it's IE:

System.getProperty("http.agent").indexOf("MSIE")>=0;

Chris

 

[Chris Berg]

Oh, maybe I was a little too fast: It doesn't work on MSIE + SUN Java
Plugin, because then "http.agent" is "Mozilla/4.0 (Windows XP 5.1)",
without the MSIE embedded. Strange enough!!

But the solution has to be close by!!

 

[Mickey Segal]

You can determine the browser type using JavaScript and feed that to the
browser via a property. There may be simpler ways, but we use this to
determine browser type and version to deal with various issues affecting
particular browsers:
www.segal.org/java/configuration/

I will check out your Runtime.getRuntime().exec("explorer "+url) approach -
it would be great to not have to pester users about popup blockers when we
already have to pester them about accepting the digital certificate.

 

[alan]

Oh, maybe I was a little too fast: It doesn't work on MSIE + SUN Java
Plugin, because then "http.agent" is "Mozilla/4.0 (Windows XP 5.1)",
without the MSIE embedded. Strange enough!!

There are dozens of JavaScript browser sniffers out there that
you can reference for all the different permutations of the
Agent header.

http://www.google.com/search?q=javascript+detect+browser

http://www.google.com/search?q=User+Agent+Strings

Cheers.

 

[Chris Berg]

Of course, but it would be much cleaner if one could determine the
browser from inside the java code itself. Mixing too much with
JavaScript quickly becomes a mess.

Chris

 

[Andrew Thompson]

I will check out your Runtime.getRuntime().exec("explorer "+url) approach -

Check out 'BrowserLauncher' first Mickey. It is a much more
rigorous approach to launching the default browser from either
an application or signed applet.

( And BTW. Any attempt to perform 'browser sniffing' with JS
is doomed to failure, for the many reasons of which the folks
on the JS group can expound at length. )

 

[Andrew Thompson]

There are dozens of ..

...extremely bad..

..JavaScript browser sniffers out there that
you can reference for all the different permutations of the
Agent header.

Including the one I just typed in?

Wooow, that's some funky JS! ;-)

 

[Andrew Thompson]

But the solution has to be close by!!

As soon as you find it, (and no, you are not even warm) you
have a month (I estimate) before the pop-up blockers catch up.

Did you even *read* the post to which I linked, or are you intending
to continue asking this question until you (falsely) convince
yourself that you can use Java to force ..anything on users.

A simple 'Java Pop-Up Blocker' might merely disable Java in the UA.
What do you intend doing then?

 

[Chris Berg]

Aah! Got that fixed as well: I forgot, you can generate the JS code
fron inside Java, so no need to make script in the html. Here goes:

netscape.javascript.JSObject navigator =
(netscape.javascript.JSObject)
netscape.javascript.JSObject.getWindow(applet)
.getMember("navigator");
String browser = (String)navigator.getMember("userAgent");
isMsIe = browser.indexOf("MSIE")>0;

Any comments to this?

Chris

 

[Andrew Thompson]

isMsIe = browser.indexOf("MSIE")>0;

Ask the experts (like I keep telling you)
<http://groups.google.com.au/groups?hl=en&lr=&scoring=d&q=detect+useragent+group:comp.lang.javascript>

Look in particular for posts by Richard Cornford, Michael Winter,
...Randy Webb, Lasse Reichstein Nielsen are some of the more
experienced JS'rs who came up in the first couple of pages that
you might research for further advice on the nature and
reliability of the User Agent string.

You would probably find a lot of similar posts on the ..
<http://groups-beta.google.com/group/comp.infosystems.www.authoring.stylesheets>
...&..
<http://groups.google.com.au/groups?hl=en&lr=&ie=UTF-8&group=comp.infosystems.www.authoring.html>
...groups.

You would have a better chance of discovering the core rendering
engine of an UA by attempting to detect it's behaviour in relation
to 'CSS import hacks', than by relying on the UA string.

 

[Mickey Segal]

I would check how well the JavaScript invocation is supported in various
platforms.

I tried the approach of launching browser windows using:
Runtime.getRuntime().exec("explorer "+url);
and it seems to work pretty well for browser windows (though I will check
out Andrew Thompson's advice on 'BrowserLauncher').

However, what arguments for exec does one use to launch a new e-mail pane
instead of using showDocument(new URL("mailto:" + address))?

 

[Mickey Segal]

On Wed, 12 Jan 2005 18:37:39 -0500, Mickey Segal wrote:

Check out 'BrowserLauncher' first Mickey. It is a much more
rigorous approach to launching the default browser from either
an application or signed applet.

The goal is not to launch the default browser; it is to launch Internet
Explorer, because the pop-up blockers in Firefox/Netscape and Macintosh
don't block showDocument and we can use showDocument for those browsers.

 

[Chris Berg]

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.

Anyway, I now found out how to do it, by using a combination of
JSObject browser-checking and System.exec("explorer "+fileName/URL).

So thanks for the help, and please don't always assume that people
have malicious intents.

Chris

 

[Mickey Segal]

Don't take it personally. I got the same reaction a few months ago when I
brought up the same issues, despite explaining that we use a signed applet.

If you can help figure out the final piece in the puzzle, how to use mailto
URLs, that would be appreciated. I know how to do that with
showDocument(new URL("mailto:" + address)) but I don't know the proper exec
call to summon the e-mail program and pass along the information.

 

[Chris Berg]

Come to think of it, my applet also has a "mailto;...." url that gets
fired using showDocument(). But actually, I don't think it gets caught
by the popup-blockers, it just (pure magic) fires the default mail
client directly without an extra empty IE window.

Or?

Chris