Pop-up detection advice needed by Java folks

[Mickey Segal]

On comp.lang.java.programmer we are discussing problems created for Java
programs by pop-up blockers (in the thread "showDocument blocked by new
microsoft pop-up blocker"). Our problem is that Java's showDocument method,
which opens new browser windows, is blocked by some pop-up blockers. The
showDocument method is blocked even if the user clicked a button in a Java
program to call showDocument. As a result, a type of user-initiated
functionality allowed in an HTML page is blocked in a Java applet.

We understand the Java programmers are collateral damage in a larger fight,
but would like advice on using JavaScript to detect pop-up blockers.

Our problem is restricted to certain environments. The Netscape and Safari
pop-up blockers do not block showDocument. In contrast, the Google and
Microsoft pop-up blockers do block showDocument. We would like to detect
pop-up blockers in appropriate environments and tell the user that the our
Java software won't work well unless they add the site to their pop-up
trusted sites.

We have seen various mentions of there being no good way to detect pop-up
blockers. However, since our needs seem restricted to Internet Explorer on
Windows our needs may be simpler than solving the general problem. Is the
following code appropriate for detecting pop-up blockers in Internet
Explorer for Windows (see it in action at
http://www.segal.org/js/pop_detect/):

Main page:

<script language = javascript>
result = window.open("popped.html", "popped", "width=10, height=10,
location=no, menubar=no, status=no, toolbar=no, scrollbars=no,
resizable=no");
if (result != null) html = "is not blocking";
else html = "is blocking";
document.write(html);
</script>

Popped-up page:

<script language = javascript>
window.close();
</script>

If this code would not be appropriate it would be helpful to know why, and
it would be even more helpful to know of code that would work better.

 

[kaeli]

We understand the Java programmers are collateral damage in a larger fight,
but would like advice on using JavaScript to detect pop-up blockers.

Good luck.
Every time someone figures it out, people use it for bad things, then newer
blockers go around it, and so on...

We would like to detect
pop-up blockers in appropriate environments and tell the user that the our
Java software won't work well unless they add the site to their pop-up
trusted sites.

Your best bet is simply to place that message on the page for all to read.
But, see my comments below...

Main page:

<script language = javascript>

The language attribute is deprecated. Use type.

result = window.open("popped.html", "popped", "width=10, height=10,
location=no, menubar=no, status=no, toolbar=no, scrollbars=no,
resizable=no");
if (result != null) html = "is not blocking";

If result is null, it may easily be that the page hasn't finished loading
because of a slow connection. Or the user may have closed it quickly with (I
think) the F4 key.

All it tells you is that the window isn't there. Not WHY it isn't there.

else html = "is blocking";
document.write(html);

document.write has many, many problems I won't go into here because you're
just using it for a test. Should you wish to use it in real code, beware.

Anyway, if there were a good way to tell if a user had a popup blocker, it
would be making money already. *grins*
So, sorry, there just isn't a way to tell this exactly with normal client-
side javascript. You can tell if a window handle is defined or not, but you
just can't tell the root cause of a null handle.

(note: if you are using an HTA or ActiveX, you can go rooting around the
user's registry, permissions allowing, but that isn't really valid in this
discussion, as you'd have to know the name of the blocker, and so on)

--
--
~kaeli~
User: The word computer professionals use when they mean
'idiot'.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

 

[Michael Winter]

[snip]

If result is null, it may easily be that the page hasn't finished
loading because of a slow connection. Or the user may have closed it
quickly with (I think) the F4 key.

Alt+F4 closes an application in Windows. I'd use Ctrl+F4 to close a MDI
child (an Opera tab).

All it tells you is that the window isn't there. Not WHY it isn't there.

I seem to remember in the last major discussion several months ago that
pop-up blockers can fake a window object. Getting an object reference
doesn't really mean anything, but at least you won't generate an error (if
you feature test before using methods, of course).

[snip]

User: The word computer professionals use when they mean'idiot'.

LOL. That's good.

Mike

 

[Mickey Segal]

Your best bet is simply to place that message on the page for all to read.

That is what we do now, but the problem is that the users wait until the
first pop-up that they need is blocked. Then they allow site pop-ups.
Unfortunately, the operation of allowing site pop-ups re-starts a Java
applet and the user loses their work. This re-starting occurs for both the
Google and Microsoft pop-up blockers.

The language attribute is deprecated. Use type.
<script type="text/javascript">
Thanks.

If result is null, it may easily be that the page hasn't finished loading
because of a slow connection. Or the user may have closed it quickly with
(I
think) the F4 key.

The pop-up window is not downloaded; it is created by the original page, so
I don't think we will run into download time issues here. I've tried to
catch that window and close it manually but it is much too fast. (BTW, is
there some way to position the popped window at a particular location so it
would be less likely to be noticed by the user?)

Anyway, if there were a good way to tell if a user had a popup blocker, it
would be making money already. *grins*

A user is not going to agree to site pop-ups if they don't truat the site.
Our users have already accepted our digital certificate, yet they have lower
privileges for button-initiated pop-ups that does a regular HTML page.

BTW, I just tried Firefox for Windows, and like Netscape it also allows
Java's showDocument.

 

[Randy Webb]

The pop-up window is not downloaded; it is created by the original page, so
I don't think we will run into download time issues here. I've tried to
catch that window and close it manually but it is much too fast. (BTW, is
there some way to position the popped window at a particular location so it
would be less likely to be noticed by the user?)

Its not download issues, its speed issues. A window being loaded is more
than just the download. The window has to open, then it has to read what
its going to display, and then go about displaying it. You are opening
the window and then immediately check to see if the window is there.
Thats leading into a disaster because of timing issues.

 

[Richard Cornford]

Mickey Segal wrote:

Our problem is that Java's showDocument method,
which opens new browser windows, is blocked by
some pop-up blockers. The showDocument method
is blocked even if the user clicked a button in
a Java program to call showDocument. As a
result, a type of user-initiated functionality
allowed in an HTML page is blocked in a Java
applet.

Yes, content inserting/re-writing proxy style pop-up blocker that
recognise a concept of "requested" pop-ups usually add code to monitor
user interactions on DOM elements are probably incapable of picking
those events up from applets (they are also usually not that well
written in JS terms).

<script language = javascript>

Apart from what Kaeli mentioned:-

result = window.open("popped.html", "popped", "width=10,
height=10, location=no, menubar=no, status=no, toolbar=no,
scrollbars=no, resizable=no");

The "features" list provided as the third argument to the -
window.open - method is specified as a comma separated list not a
comma-space separated list. Including the spaces will prevent the
features being acted upon in some browsers.

if (result != null) html = "is not blocking";

If you are having problems with an applet method why are you not testing
by attempting to open the window with that method?

As has been mentioned, a null result will be a blocked window, but
pop-up blockers use a range of methods, some of which return dummy
window objects, others return a reference to the current window object,
while others act asynchronously and might not have got round to closing
the new browser instance at this point.

The most potentially reliable approach proposed to date is to have the
test window open a resource that would then use JS to report back to the
window that opened it when it loaded. A window blocked by any method
will not load the resource, but other factors might also prevent it from
loading (including user action). If the resource lads and reports back
then pop-ups are viable on the user's system. There is also the timing
issue; how long do you give the resource to load before assuming that it
never will.

else html = "is blocking";
document.write(html);
</script>

Popped-up page:

<script language = javascript>
window.close();
</script>

If this code would not be appropriate it would be
helpful to know why, and it would be even more
helpful to know of code that would work better.

To determine whether there is a better way (or better ways, and so
possibly a best way) it would be necessary to know what this pop-up
window is for. It is unlikely that trying to detect pop-up blockers
would prove the best solution.

Generally it strikes me that pop-up find there way into web application
GUIs because they seem to be an easy solution, at least so long as the
actions of pop-up blockers are not taken into account. I notice from the
c.l.j.p thread that you are already requiring JS to be available on the
client, and I suspect that condition also implies that only modern(ish)
dynamic browsers are being supported, so there are quite a lot of
alternative possibilities in scripted UI components.

<URL: http://www.litotes.demon.co.uk/js_info/pop_ups.html >

Richard.

 

[Mickey Segal]

Mickey, why do I get the impression you did not
look closely over the suggestions I made here..
<http://google.com/[email protected]&rnum=13>

Your code uses the same approach as the code at
http://www.segal.org/js/pop_detect/. I did not add features such as
JavaScript detection because we already do that; I was trying to show the
simplest program to illustrate the essence of the pop-up detection.

If you are referring to differences such as testing for 'undefined' instead
of 'null' it would be helpful if you explained why that change is important.
Also, it was not clear why adding 'text/css' to the sample code was of
importance.

 

[Mickey Segal]

Generally it strikes me that pop-up find there way into web application
GUIs because they seem to be an easy solution, at least so long as the
actions of pop-up blockers are not taken into account. I notice from the
c.l.j.p thread that you are already requiring JS to be available on the
client, and I suspect that condition also implies that only modern(ish)
dynamic browsers are being supported, so there are quite a lot of
alternative possibilities in scripted UI components.

Avoiding showDocument in a Java applet is like avoiding hyperlinks in an
HTML page: it can be done, but defeats much of the purpose of the internet.
The Google and Microsoft pop-up blockers block a Java applet from having a
hyperlink that when clicked brings up another Web page without destroying
the Java applet. The effect of the pop-up blockers on an HTML page is much
milder, only blocking the equivalent of self-clicking hyperlinks.

<URL: http://www.litotes.demon.co.uk/js_info/pop_ups.html >

Clearly there are many different implementations of JavaScript in different
browsers and many different implementations of pop-up blockers, but as long
as the only showDocument issue is with Google and Microsoft pop-up blockers
in Internet Explorer for Windows we may be dealing with a simpler problem
with a simpler solution. If pop-up blockers start having different versions
with different blocking strategies then we have a much bigger mess, similar
to the woes we have in dealing with different Java versions in different
environments.

Is there some reason why it would be a problem for pop-up blockers to
announce their presence with some JavaScript property?

 

[Richard Cornford]

Avoiding showDocument in a Java applet is like avoiding
hyperlinks in an HTML page: it can be done, but defeats
much of the purpose of the internet.

Is the - showDocument - method really the problem? I would have thought
that attempting to use it to navigate the current window would be
totally uninfluenced by pop-up blocking. That is the activity that is
analogous to hyperlinks. Your problem is with attempting to target new
windows with the method, and targeting new windows with hyperlinks is
already unavailable in the strict DTDs of HTML 4.01 and XHTML 1.0. It is
unlikely that the W3C would remove the target attribute from HTML if it
were really fundamental to the Internet.

The Google and Microsoft pop-up blockers block a Java applet
from having a hyperlink that when clicked brings up another
Web page without destroying the Java applet. The effect of the
pop-up blockers on an HTML page is much milder, only blocking
the equivalent of self-clicking hyperlinks.

Whinging about the reality of the situation is not going to get you
anywhere. It would be much more productive to examine the possibility of
achieving the desired effect in a way that was outside the influence of
pop-up blockers of any kind. But as you are unwilling to, or incapable
of explaining what the desired effect actually is you are on your own as
far as that goes.

Clearly there are many different implementations of
JavaScript in different browsers

Not really; ECMA 262 (3rd edition) specifies an adequate sub-set of
javascript behaviour that is seemingly consistently implemented in
current web browsers.

and many different implementations of pop-up
blockers,

Certainly many more than you appear to be aware of.

but as long as the only showDocument issue is with Google
and Microsoft pop-up blockers in Internet Explorer for Windows
we may be dealing with a simpler problem with a simpler solution.

I would be very surprised if they were the only pop-up blocking
mechanisms adversely affecting attempts by Java applets to open new
windows. All of the external pop-up blockers that act by killing off any
new instances of IE would probably have a very similar effect (and apply
their actions to hyperlinks, form submissions and buttons with equal
vigour).

If pop-up blockers start having different versions strategies
with different blocking strategies

Move that statement into the past-tense.

then we have a much bigger mess,

Nothing has chanced. It is, and will remain, unreliable to attempt to
open a new browser instance from a web page by any method.

similar to the woes we have in dealing with different
Java versions in different environments.

Nothing has chanced. It is, and will remain, unreliable to attempt to
open a new browser instance from a web page by any method. (There are,
after all, browsers that simply do not provide any window opening
mechanism at all).

Is there some reason why it would be a problem for pop-up
blockers to announce their presence with some JavaScript
property?

It would mean that people who ran pop-up blockers would be constantly
hassled to turn them off. they don't want to turn them off because they
don't want pop-ups, so the manufacturers of pop-up blockers are well
motivated to make it as difficult as possible to detect the action of
their pop-up blockers.

Richard.

 

[Mickey Segal]

Ultimately, ..I suppose I was displaying my
irritation in that I had concluded days ago
that this could be achieved *entirely* *in*
*Java*, and you did not seem to be hearing me..

Andrew:

It is best to express such concerns directly so they can be addressed. As
mentioned in the comp.lang.java.programmer thread, there are advantages to
fleshing out both the Java and JavaScript approaches. One advantage of
consulting the JavaScript experts is that they think about pop-up window
problems much more Java experts do. The suggestion in the
comp.lang.java.programmer thread to consult the JavaScript experts was a
good one, brought up, as it happens, by you.

Although it makes sense to address concerns about the Java approach in
comp.lang.java.programmer, since you mentioned the issue I will bring up two
concerns:
1. Since pop-up blocking is done in so many different ways, are we
confident that the Java socket approach is fully robust?
2. I don't know if you had a chance to try your test applet
(http://www.physci.org/test/showdoc/) under Windows XP SP2. The following
dialog pops up: "To help protect your computer, Windows Firewall has blocked
some features of this program. Do you want to keep blocking this program?
Name: Internet Explorer". This is not the sort of message you want as the
introduction to your software.

 

[Mickey Segal]

Is the - showDocument - method really the problem? I would have thought
that attempting to use it to navigate the current window would be
totally uninfluenced by pop-up blocking. That is the activity that is
analogous to hyperlinks.

In many Java environments, navigating the current window to a new URL
terminates the Java applet at the original URL.

Your problem is with attempting to target new
windows with the method, and targeting new windows with hyperlinks is
already unavailable in the strict DTDs of HTML 4.01 and XHTML 1.0.

A huge number of Web sites have user-initiated opening of new browser
windows. None of the common pop-up blockers stop such user-initiated
pop-ups. In contrast, user-initiated pop-ups are blocked from Java. It is
not clear if this blocking is by design or an error. Google responded to
the blocking of user-initiated pop-ups illustrated at
http://www.segal.org/java/pop_window/ by writing "We are aware of this error
and our engineering team is working to correct it." However, no correction
appeared and Microsoft did the same thing.

Whinging about the reality of the situation is not going to get you
anywhere. It would be much more productive to examine the possibility of
achieving the desired effect in a way that was outside the influence of
pop-up blockers of any kind. But as you are unwilling to, or incapable
of explaining what the desired effect actually is you are on your own as
far as that goes.

Although the entire focus of this thread has been on ways to deal with the
current situation as it is that does not make normative asides
inappropriate.

Since you asked so politely for more details about what we want to achieve
with pop-up windows, here are two examples of things that users of our
software (mostly using Java 1.1) can do:
1. Click a Reference button and see a new browser window with a paper from
the scientific literature expanding on information in our database. These
papers are at external URLs.
2. Click a Printable Page button and get a summary Web page they can paste
into other programs or print.

 

[Mickey Segal]

What's the difference between the original
and summary page? If the summary information
is *contained* in a more complex page, you can write
a print style-sheet that hides the majority of
the extraneous detail specifically for printing..

The original page has a Java (1.1) applet. The summary page is an HTML
document listing the information they entered (with hyperlinks back to the
software), conclusions and another summary hyperlink back to the software.
The purpose is for users to print out the HTML page or paste it into
HTML-aware documents, allowing them to return to the software when they have
more information, document their work and share their work with others.

 

[Richard Cornford]

In many Java environments, navigating the current window to a
new URL terminates the Java applet at the original URL.

But when Java initiates that navigation it is in a position to know that
it will be terminated as a consequence and persist its current internal
state on the server.

A huge number of Web sites have user-initiated opening of
new browser windows.

The vast majority of web sites are authored by individuals with little
or no understanding of the technologies they purport to be using and a
total unawareness of the issues surrounding their use. Often the results
are barely functional on default configurations of IE running on default
installations of a Windows OS. And as soon as Microsoft alter any
default state those individuals start to get indigent that the half-ass
hacks they have been using suddenly stop working as they had previously.

Appealing to the precedence provided by a numerical majority is not a
recipe for quality software authoring when the average is so poor.

None of the common pop-up blockers stop such
user-initiated pop-ups.

All the pop-up blockers I have ever seen are capable of stopping all
pop-ups of any type. The better ones tend not to default to do that but
you may not have made an accurate assessment of what qualifies as common
on the world of pop-up blocking. You seem to be assuming that google
tool bar and Microsoft's new pop-up blocking define the common methods.
My guess would be that personal-firewall/internet-security style
programs (content-inserting/re-writing proxies) make up the real
majority, and they are often in a very bad position to draw distinctions
between "requested" and "unrequested" pop-ups.

In contrast, user-initiated pop-ups are blocked from Java.

Strictly those would be Java initiated pop-ups. The fact that Java is
opening them as a direct consequence of user action is clearly not known
to the pop-up blocking mechanisms.

It is not clear if this blocking is by design or an error.

The applet plug-ins are presumably not propagating UI events into the
containing DOM where they could be observed and used to make a judgement
about pop-ups. Probably that was a design error, but not unexpected as
at the time it would have been difficult to anticipate the extent to
which pop-ups would be abused for antisocial purposes.

Google responded to the blocking of user-initiated
pop-ups illustrated at http://www.segal.org/java/pop_window/
by writing "We are aware of this error and our engineering
team is working to correct it." However, no correction
appeared and Microsoft did the same thing.

You shouldn't hold your breath.

Although the entire focus of this thread has been on ways
to deal with the current situation as it is that does not
make normative asides inappropriate.

I don't see any evidence of trying to deal with the current situation.
You seem to be trying to find a way of using pop-ups in a world where
they would be best consigned to history and the desire to use them
designed out of Internet systems.

Since you asked so politely for more details about what we
want to achieve with pop-up windows, here are two examples
of things that users of our software (mostly using Java 1.1)
can do:
1. Click a Reference button and see a new browser window with
a paper from the scientific literature expanding on information
in our database. These papers are at external URLs.

Navigation within the current window will result in the user seeing the
referenced resource, they can use the back button to return to the
previous page. The state of the Java applet can be transferred to, and
restored from, the server.

Alternatively, IFRAME elements within positioned DIVs scripted into
in-window pop-ups would be in a position to show external resources on
javascript enabled modern dynamic browsers without leaving the current
page.

2. Click a Printable Page button and get a summary Web
page they can paste into other programs or print.

Ditto, plus printer specific style-sheets.

Richard.