Popup Blocker Detection

[Raffi]

Hi,

We have a database application that runs in a popup Internet Explorer
application window. The reason for this is to isolate the casual user
from the address bar and the typical IE navigation buttons.

The application has a browser test page that displays an error message
when a popup blocker is found and opens a popup page stating the test
was successfull if there is no popup blocker.

Is there a reliable method (preferably javascript) for detecting the
major popup blockers (SP2, AOL, Yahoo, Google, MSN, etc.)? We currently
have a temporary solution in place which works OK but we would like to
have a better solution.

We have already reasearched this on the net, as well as spent a few
hours trying different options.

The application is designed to run on MSIE only so the solution can be
Explorer specific.

Thanks,
Raffi

[Greg N.]

Raffi wrote:

We have a database application that runs in a popup Internet Explorer
application window. The reason for this is to isolate the casual user
from the address bar and the typical IE navigation buttons.
God, do I hate that. Can't stop loading the frickin page, can't reload
it, can't go back, can't easily see the URL, nothing. So much about
reasons not to like pops like that. Can anybody come up with a
plausible reason why this kind of uncontrollable pops are a good idea
for some users?
Is there a reliable method (preferably javascript) for detecting the
major popup blockers (SP2, AOL, Yahoo, Google, MSN, etc.)
Loks to me like somebody working on state of the art intrusive
advertising technology is asking user community for help. I may be
wrong, so please tell us what kind of app this really is.
The application is designed to run on MSIE only so the solution can be
Explorer specific.

Sure. Reaching 70% of the users is good enough in only one environment:
Advertising. Please tell me I'm wrong.

[Raffi]

Greg N. wrote:

Raffi wrote:

We have a database application that runs in a popup Internet Explorer application window. The reason for this is to isolate the casual user from the address bar and the typical IE navigation buttons.
God, do I hate that. Can't stop loading the frickin page, can't

reload it, can't go back, can't easily see the URL, nothing. So much about
reasons not to like pops like that. Can anybody come up with a
plausible reason why this kind of uncontrollable pops are a good idea for some users?

Is there a reliable method (preferably javascript) for detecting the major popup blockers (SP2, AOL, Yahoo, Google, MSN, etc.)
Loks to me like somebody working on state of the art intrusive
advertising technology is asking user community for help. I may be
wrong, so please tell us what kind of app this really is.

The application is designed to run on MSIE only so the solution can be Explorer specific.

Sure. Reaching 70% of the users is good enough in only one

environment: Advertising. Please tell me I'm wrong.

Well, you're wrong. But considering the amount of crap on the internet,
I don't really blame you. The application is a web based database and
data analysis program which is used by a non computer savvy audience.
We designed it to be simple and for the user to navigate through the
application using the navigation buttons integrated in the
appliacation. Also, the program launches reports using popups to keep
the main session screen intact. That should be enough information to
dispell any ill intent.

BTW, I'm a strong believer of popup blockers. I have 2 of them on my
PC. Popups when used properly are a great tool. Sadly though,
legitimate applications that use popups have become more cumbersome to
implement because of their misuse.

Raffi

[Mark Preston]

Raffi wrote:

Greg N. wrote:

Raffi wrote:

[snip] So much about reasons not to like pops like that. Can
anybody come up with a plausible reason why this kind of
uncontrollable pops are a good idea for some users?

As a pop-up, no. As an application, sure.

Is there a reliable method (preferably javascript) for detecting
major popup blockers (SP2, AOL, Yahoo, Google, MSN, etc.)

Loks to me like somebody working on state of the art intrusive
advertising technology is asking user community for help. I may be
wrong, so please tell us what kind of app this really is.

[snip]

[snip] The application is a web based database and data analysis
program which is used by a non computer savvy audience. We designed
it to be simple and for the user to navigate through the application
using the navigation buttons integrated in the appliacation. Also,
the program launches reports using popups to keep the main session
screen intact. That should be enough information to dispell any ill
intent.

I have to be honest and admit that I can see no reason whatsoever for it
now. If you need web-rendering, but not a browser, and you are writing
it for an application then why the hell not actually WRITE an application?

Surely it is a lot easier just to drop an HTML control into a simple
application rather than all this buggering around with a (relatively)
standard browser?

[kaeli]

In article <11**********************@z14g2000cwz.googlegroups .com>,
th*********@yahoo.com enlightened us with...

Is there a reliable method (preferably javascript) for detecting the major popup blockers (SP2, AOL, Yahoo, Google, MSN, etc.)

No. If there were, don't you think all the baddies would have found it by
now? ;)

And even if there really were, do you think we'd post it here, were anyone
wanting to abuse it could find it?
Your intentions might be perfectly benign, but any idiot can read these
public newsgroups.

Do what everyone else with a legit need for popups does -- put a message
there telling your users that your site uses popups and to put it in their
allow list or whatever.
Also, most blockers block *unrequested* popups. So if the user really IS
clicking on something and it pops a new window, that shouldn't be blocked
anyway.

--
--
~kaeli~
God was my co-pilot... but then we crashed in the mountains
and I had to eat him.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[J Wynia]

Mark Preston wrote:

I have to be honest and admit that I can see no reason whatsoever for it
now. If you need web-rendering, but not a browser, and you are writing
it for an application then why the hell not actually WRITE an application?

Surely it is a lot easier just to drop an HTML control into a simple
application rather than all this buggering around with a (relatively)
standard browser?

There are lots of reasons that applications are being implemented as web
applications and, believe it or not, they're legitimate reasons. I know,
I know, *you've* never seen the reasons, but I'm pretty sure you haven't
faced every software problem in existence (though I've been wrong before).

Yours is a typical reaction in web development discussions when someone
asks how to do something restrictive or authoritarian: an assumption
that we're talking about a web "site" that is publicly available and
fits your idea of a "site". The thing is, there's an AWFUL lot of web
work that is done outside of that scope. Over the last 5 years, well
over 85% of the web development I've done and participated in
development is behind the firewall. We're talking about projects costing
over $3 million and used by 10's of thousands of users, all of whom work
for the same company. Is that a lot of money for a web application?
Absolutely. In several of those cases, did the previous non-web
application (the one you insist must be easier to build) cost $5-6
million in total costs for similar effort? Yes, again.

When you're talking about deploying a critical piece of software that
was already needing the client/server model, the web is often much
cheaper than the alternative. You can standardize the clients/browsers
and deploy bugfixes, enhancements and upgrades to all machines by simply
upgrading the web app on the web server. You don't need to fight with
pushing out software upgrades across the world or FedEx'ing CD-ROM's all
over the place. You also don't need to worry about users cancelling the
upgrade (to bypass the interruption) and continuing to use an old
client. You can also control the machine where the application itself is
installed, since it's entirely on the server. There's no trying to
figure out why a certain desktop won't let the app install only to find
out some stupid screensaver they added has messed up their registry. The
cycle for making changes in response to the users' feedback is also
drastically improved. Couple that with roaming users who use the same
application across multiple machines and maintaining consistency and
you've got just a few of the major reasons why something that would be
an irritating faux pas on the web at large (popups used for advertising)
turn into a much appreciated feature (new windows used as modal dialogs
for an application) in a different setting.

Here in reality, deployment, support, etc. often cost more than the
developer time to build the application in the first place.

In my current application, we use new windows as a destination for Excel
exports. Users specifically requested the functionality to enable them
to have several exported reports open simultaneously to do comparisons
before deciding exactly which report to finally export and save. For the
most part, this didn't cause problems because 90% of the users of this
application are using locked down machines in common areas. However, the
remaining 10% are using their work desktop machine and several have
installed additional popup blockers, resulting in complaints.

In this case, this is a very small drop in the bucket (as are most of
these types of issues) that would just be nice to solve with a quick bit
of JS (a 20 minute solution, costing the project very little).

[Mr.Clean]

In article <Xv********************@speakeasy.net>, jw****@speakeasy.net says...

However, the
remaining 10% are using their work desktop machine and several have
installed additional popup blockers, resulting in complaints.

Most popup blockers have settting where you can ALLOW popups from specific
domains, have you tried notifying your users to modify those settings?

[kaeli]

In article <d4*******************@news.demon.co.uk>, us****@nosource.co.uk
enlightened us with...

>

I have to be honest and admit that I can see no reason whatsoever for it
now. If you need web-rendering, but not a browser, and you are writing
it for an application then why the hell not actually WRITE an application?

Off the top of my head...
* Banking applications.
* Intranet applications with multiple OSs in use (no installation necessary)
-- this was the reason my biggest web app came to be.
* Intranet applications with multiple OS versions in use (same).
* CD-ROM applications.
* Financial / trading applications.
* B2B applications

All of those do very well as web applications and not so well as installed
applications. Not to mention the ease of patching web applications. Plus,
using SSL and other technologies to ensure the security and privacy of data
sent between the client and the server is, IMO, much easier to do than trying
to run encryption algorithms and protect ports on multiple PCs where you
don't know who has what else installed. I'm no security expert by any means,
though, so take that last bit with a grain of newbie-ness.
Surely it is a lot easier just to drop an HTML control into a simple
application rather than all this buggering around with a (relatively)
standard browser?

You don't code installed applications, do you? ;)
I've had to a couple times.
I promise you that it isn't as easy as just dropping a control onto a form
and thinking it will work for every person who tries to use the application,
whether they have windows 95 or windows 2000 professional SPx. Or, $diety
forbid, you're stuck with users who have windows, users who have macs, and
users who have solaris. Like we do here.
Not to mention the fact that only certain development technologies even HAVE
a browser component (mostly I'm thinking .net). You don't want to try to
write a rendering engine yourself, with a JS interpreter and all, do you?

--
--
~kaeli~
A little rudeness and disrespect can elevate a meaningless
interaction to a battle of wills and add drama to an
otherwise dull day.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[Raffi]

kaeli wrote:

In article <d4*******************@news.demon.co.uk>, us****@nosource.co.uk enlightened us with...

> I have to be honest and admit that I can see no reason whatsoever for it now. If you need web-rendering, but not a browser, and you are writing it for an application then why the hell not actually WRITE an application?

Off the top of my head...
* Banking applications.
* Intranet applications with multiple OSs in use (no installation

necessary) -- this was the reason my biggest web app came to be.
* Intranet applications with multiple OS versions in use (same).
* CD-ROM applications.
* Financial / trading applications.
* B2B applications

All of those do very well as web applications and not so well as installed applications. Not to mention the ease of patching web applications. Plus, using SSL and other technologies to ensure the security and privacy of data sent between the client and the server is, IMO, much easier to do than trying to run encryption algorithms and protect ports on multiple PCs where you don't know who has what else installed. I'm no security expert by any means, though, so take that last bit with a grain of newbie-ness.

Surely it is a lot easier just to drop an HTML control into a simple application rather than all this buggering around with a (relatively) standard browser?
You don't code installed applications, do you? ;)
I've had to a couple times.
I promise you that it isn't as easy as just dropping a control onto a

form and thinking it will work for every person who tries to use the application, whether they have windows 95 or windows 2000 professional SPx. Or, $diety forbid, you're stuck with users who have windows, users who have macs, and users who have solaris. Like we do here.
Not to mention the fact that only certain development technologies even HAVE a browser component (mostly I'm thinking .net). You don't want to try to write a rendering engine yourself, with a JS interpreter and all, do you?
--
--
~kaeli~
A little rudeness and disrespect can elevate a meaningless
interaction to a battle of wills and add drama to an
otherwise dull day.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Thanks for the good responses. Though not providing an actual solution,
they do cover the reasons why we went with an IE based client
interface. It would have been nice if popup blockers had some practical
exclousions built in, like allowing popups on secure connections from
authenticated hosts? This would solve our problem since the application
only accepts HTTPS connections.

Raffi

[kaeli]

In article <11**********************@l41g2000cwc.googlegroups .com>,
th*********@yahoo.com enlightened us with...

Thanks for the good responses. Though not providing an actual solution,
they do cover the reasons why we went with an IE based client
interface. It would have been nice if popup blockers had some practical
exclousions built in, like allowing popups on secure connections from
authenticated hosts? This would solve our problem since the application
only accepts HTTPS connections.

There is another possible solution, especially since you only have one
browser to worry about.
Don't use popups at all.
Use "fake" popups. Floating DIVS styled to look like windows (can be moved,
"minimized" (hidden, really) etc) that get their dynamic content from the
server. This is quite possible now, though it is somewhat new.
xmlhttp
http://www.15seconds.com/issue/020606.htm

The downside is that it isn't an independent window, so it can't be open when
the main window is out of focus, and it won't retain state by itself if the
window content is reloaded, but for this type of app, it doesn't sound like
that would be a bad thing, anyway. And since it doesn't instantiate a new IE
instance, it uses less memory, too.

Just a thought.

--
--
~kaeli~
What do they use to ship styrofoam?
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

[Prowler]

"kaeli" <ti******@NOSPAM.comcast.net> wrote in message
news:MP************************@nntp.lucent.com...

In article <d4*******************@news.demon.co.uk>, us****@nosource.co.uk
enlightened us with...

>

I have to be honest and admit that I can see no reason whatsoever for it
now. If you need web-rendering, but not a browser, and you are writing
it for an application then why the hell not actually WRITE an
application?

Off the top of my head...
* Banking applications.
* Intranet applications with multiple OSs in use (no installation
necessary)
-- this was the reason my biggest web app came to be.
* Intranet applications with multiple OS versions in use (same).
* CD-ROM applications.
* Financial / trading applications.
* B2B applications

<<::snip::>>

Agreed. I am currently working on an application which heretofore was
strictly EDI-based (i.e. B2B) and which we are converting to a Web
application. It will still have the same permissions requirements,
restrictions, etc. that it has as an AS/400 5250 green screen app, but will
be available to trading partners via secured server on the Web. Because of
the nature of the underlying AS/400 app, which must continue to run
**unaltered** on the 5250 terminals, we do not allow use of the Back or Home
button, or even Refresh (other than right-click refresh), because for the
app to function, navigation **must** conform to the menu system in use on
the 5250 app. Fortunately, we do not need popups, but we do need to restrict
navigation. We have chosen not to limit browser chrome; it won't take being
dumped back to the login screen too many times for users to figure out that
the menus are the way to go. The only way to go.

I would say that kaeli's list is a fairly accurate accounting of many of the
applications which might lead to the development of a Web-based (i.e.
browser based) application versus a platform-specific,
change-management-plagued, application-development-environment-limited
dedicated application.

Cheers,
Scott
Cheers,
Scott

[Tony]

"Raffi" <th*********@yahoo.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

Well, you're wrong. But considering the amount of crap on the internet,
I don't really blame you. The application is a web based database and
data analysis program which is used by a non computer savvy audience.
We designed it to be simple and for the user to navigate through the
application using the navigation buttons integrated in the
appliacation. Also, the program launches reports using popups to keep
the main session screen intact. That should be enough information to
dispell any ill intent.

BTW, I'm a strong believer of popup blockers. I have 2 of them on my
PC. Popups when used properly are a great tool. Sadly though,
legitimate applications that use popups have become more cumbersome to
implement because of their misuse.

Why not just tell your users to set their popup blocker to allow popups from
your site?

[RobG]

Raffi wrote:

kaeli wrote:
[...]
Thanks for the good responses. Though not providing an actual solution,
they do cover the reasons why we went with an IE based client
interface. It would have been nice if popup blockers had some practical
exclousions built in, like allowing popups on secure connections from
authenticated hosts? This would solve our problem since the application
only accepts HTTPS connections.

Pop-up blockers only block unrequested pop-ups. If you make them
occur as a result of a user action (click on a button say) then they
aren't blocked (though I've not used any with IE, only other
browsers).

Also, most pop-up blockers (e.g. Firefox) can be set to allow pop-ups
from 'Allowed Sites'.

Pop-ups do make sense sometimes, particularly in the context of
dialog boxes - but having said that, I hate them in general and will
only tolerate them if I really have to.
--
Rob

[Raffi]

The program spawns popups as needed to generate reports. These popups
are not generated through direct user action, rather by the program
based on other user input (report paramenters).

As for allowing popups from specific websites, this is true and this is
what we have now. The issue is that 1)users aren't necessarily computer
savvy and 2)many people don't read manuals or instructions. So what
happens is when the user tries to generate a report or run the program
itself and get nowhere, their reaction to this is to call tech support.

So what we've done is have a browser "compatibility" test page where we
test for popup blockers, and have instructions in big bold red print on
the website asking users to test their browser for "compatibility"
before attempting to use the application. This is where the popup
blocker detection script comes into play.

Raffi

[Mr.Clean]

In article <11**********************@z14g2000cwz.googlegroups .com>, th*********@yahoo.com says...

The program spawns popups as needed to generate reports. These popups
are not generated through direct user action, rather by the program
based on other user input (report paramenters).

As for allowing popups from specific websites, this is true and this is
what we have now. The issue is that 1)users aren't necessarily computer
savvy and 2)many people don't read manuals or instructions. So what
happens is when the user tries to generate a report or run the program
itself and get nowhere, their reaction to this is to call tech support.

So what we've done is have a browser "compatibility" test page where we
test for popup blockers, and have instructions in big bold red print on
the website asking users to test their browser for "compatibility"
before attempting to use the application. This is where the popup
blocker detection script comes into play.

Well, I thought you said that you had control of all these computers, the
software, especially. Why don't you standardize on a popup blocker and
configure it yourself so you won't get support calls about them.

[RobG]

Raffi wrote:

The program spawns popups as needed to generate reports. These popups
are not generated through direct user action, rather by the program
based on other user input (report paramenters).

As for allowing popups from specific websites, this is true and this is
what we have now. The issue is that 1)users aren't necessarily computer
savvy and 2)many people don't read manuals or instructions. So what
happens is when the user tries to generate a report or run the program
itself and get nowhere, their reaction to this is to call tech support.

So what we've done is have a browser "compatibility" test page where we
test for popup blockers, and have instructions in big bold red print on
the website asking users to test their browser for "compatibility"
before attempting to use the application. This is where the popup
blocker detection script comes into play.

As a guess: run a script using a timer that displays a message like
'Please disable your pop-up blocker - click here for instructions',
then call a pop-up that has code to cancel the timer. Give the timer
say 2 seconds to allow the pop-up to appear, and display 'Please
wait, checking browser settings...' in the meantime.

If the pop-up is blocked, it won't cancel the timer and the 'disable
pop-up blocking' message will appear.

Untested, but seems like it should work (maybe this is what you are
doing already...). You could include this test very early when users
enter the site (on the way to login?) so they can only get to the
application if they've run the test and disabled pop-ups, rather than
have a separate test page.

--
Rob

[RobG]

Raffi wrote:

The program spawns popups as needed to generate reports. These popups
are not generated through direct user action, rather by the program
based on other user input (report paramenters).

As for allowing popups from specific websites, this is true and this is
what we have now. The issue is that 1)users aren't necessarily computer
savvy and 2)many people don't read manuals or instructions. So what
happens is when the user tries to generate a report or run the program
itself and get nowhere, their reaction to this is to call tech support.

So what we've done is have a browser "compatibility" test page where we
test for popup blockers, and have instructions in big bold red print on
the website asking users to test their browser for "compatibility"
before attempting to use the application. This is where the popup
blocker detection script comes into play.

Raffi

It's even easier than I suspected, no timer required. I'd make the
login a pop-up so they can't even login with pop-ups blocked - play
code below.

The only issues left is that if the user has JavaScript disabled,
they will be told they have pop-up blocking turned on, even if they
haven't. A bit of in-page scripting should fix that though.

Over to you...
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title> Check for pop-up blocker </title>
<meta http-equiv="Content-Type"
content="text/html; charset=ISO-8859-1">
<script type="text/javascript">
var zWin;
function wrt(a,b) {
zWin = window.open('','result','width=500,height=200,menu bar=0'
+ ',toolbar=1,status=0,scrollbars=1,resizable=1');
var hText = [
'<html><head><title>Pop-up Checker</title>',
'</head><body onLoad=\"self.focus();\" style=\"',
'background-color: eee; text-align: center\">',
'<h1>Pop-up blocker tester</h1>',
'<p>Your browser must be set to allow pop-ups in order to ',
'use this site. If you see this window, your browser is set ',
'to allow pop-ups.</p><p>Please click \'Close\' below ',
'to close this window.</p>',
'<a href=\"javascript:window.close();\">Close</a>',
'<script type=\'text/javascript\'>',
'opener.blockerOnMsg.style.display=\'none\';',
'opener.blockerOffMsg.style.display=\'\';',
'</sc' + 'ript>',
'</body></html>'
];
if (zWin && 'null' != zWin.document){
zWin.document.writeln(hText.join(''));
zWin.document.close();
}
}
</script>
</head><body onload="wrt('From onload','onload content');">
<h1>This is the Start Page</h1>
<div id="blockerOnMsg">You have popup blocking enabled, please
disable it. Insructions are here: <a href="
http://www.mozilla.org
">Mozilla instructions</a></div>
<div id="blockerOffMsg" style="display: none;">Thank you for not
having your pop-up blocker enabled. <a href="
http://www.mozilla.org
">Click to proceed...</a></div>

<script type="text/javascript">
var blockerOnMsg = document.getElementById('blockerOnMsg');
var blockerOffMsg = document.getElementById('blockerOffMsg');
</script>

</body></html>
--
Rob

[J Wynia]

Mr.Clean wrote:

In article <Xv********************@speakeasy.net>, jw****@speakeasy.net says...

However, the
remaining 10% are using their work desktop machine and several have
installed additional popup blockers, resulting in complaints.

Most popup blockers have settting where you can ALLOW popups from specific
domains, have you tried notifying your users to modify those settings?

I'm fully aware of those settings (and, personally, I've built custom
browsers and am pretty well aquainted with the capabilities). However,
like many Internet discussions, rather than getting the point, which was
that there are scenarios where the original poster's request is
reasonable, you latched on to a single sentence and ignored the rest. I
already solved the problem months ago and was just using it as an
example to illustrate the point.
Consider that it can take 5-10 hours of phone calls following up an
email that people didn't understand, but still took a meeting to decide
on the wording, etc. which is more expensive than half an hour of
developer time to just make it work. In almost any business, your
biggest expense is people's time. Any time you can cut people's time
with a simple piece of technology instead, you save money. Add to THAT
the fact that there were more than just the SP2 popup blocker in
question and you have to waste time figuring out all of the permutations
that have been installed. You can pretty quickly waste $10,000 in time
on a stupid problem like popups stopping a feature that the people in
question specifically requested.

[Richard Cornford]

RobG wrote:

Raffi wrote: <snip>

... test page where
we test for popup blockers, ... . This is where
the popup blocker detection script comes into play.

It's even easier than I suspected, ...

<snip>

What is easier than you suspected? What you have presented is not a -
popup blocker - detector, it is a - NOT popup blocker - detector, but
NOT - NOT popup blocker - is not a - popup blocker -. It may just be a
logical truth, but programming without a regard for logic doesn't tend
to be viable.
zWin = window.open('', ... <snip> if (zWin && 'null' != zWin.document){
zWin.document.writeln(hText.join(''));
zWin.document.close();
}

<snip>

Incidentally, some content-inserting/re-writiong proxy style pop-up
blockers return an object from calls to window.open. That object varies
from a reference to the current window (where your script promptly
replaces its contents, removing the option of responding to the result
of the test) to more normal javascript objects (that may or may not
implement a - document - property that is itself an object). Testing
scripts should generally be robust enough not to error-out as they
execute. Much more comprehensive feature testing is called for in this
context.

And the comparison with the string 'null' seems inappropriate in any
case.

Richard.

[Mark Preston]

J Wynia wrote:

Mark Preston wrote:

Surely it is a lot easier just to drop an HTML control into a simple
application rather than all this buggering around with a (relatively)
standard browser?

There are lots of reasons that applications are being implemented as web
applications and, believe it or not, they're legitimate reasons. I know,
I know, *you've* never seen the reasons, but I'm pretty sure you haven't
faced every software problem in existence (though I've been wrong before).

Actually, if you look very, very carefully I never suggested for a
moment that your application should *not* be a web-app or even a
web-service. What I suggested is that perhaps it should not be in a
general-purpose web *browser*.

[Mark Preston]

kaeli wrote:

You don't code installed applications, do you? ;)

Oh yes - for the past twenty-eight years! All your points are as totally
irrelevant as could possibly be:-

1. If you have (or may have) OS or hardware issues, use system
independent code. That is what Java was *created* for.
2. If you want to use a web *service* or web *application* that does not
mean you need a commercial web *browser*. You just need something to
render web *pages*... which is what I suggested.

[GaryBesta]

Why not use a HTA instead ?

http://msdn.microsoft.com/library/de...taoverview.asp

[Peter Wilson]

Mr.Clean wrote:

In article <11**********************@z14g2000cwz.googlegroups .com>, th*********@yahoo.com says...

The program spawns popups as needed to generate reports. These popups
are not generated through direct user action, rather by the program
based on other user input (report paramenters).

As for allowing popups from specific websites, this is true and this is
what we have now. The issue is that 1)users aren't necessarily computer
savvy and 2)many people don't read manuals or instructions. So what
happens is when the user tries to generate a report or run the program
itself and get nowhere, their reaction to this is to call tech support.

So what we've done is have a browser "compatibility" test page where we
test for popup blockers, and have instructions in big bold red print on
the website asking users to test their browser for "compatibility"
before attempting to use the application. This is where the popup
blocker detection script comes into play.

Well, I thought you said that you had control of all these computers, the
software, especially. Why don't you standardize on a popup blocker and
configure it yourself so you won't get support calls about them.

I find it interesting that these 'non-technical users' have the nouse to
install pop-up blockers, but can't use back, next, home buttons. Neither
- having installed these blockers are they capable of clicking the big
sign saying "124321000 popups blocked"

Also find it interesting that these controlled desktops in the hands of
technophobes should even have these unauthorised additions. Basically
that says they are not controlled desktops at all.

Most of the pop-up blockers do indeed allow pop-ups as the result of
user action. Not sure I understand this 'will pop-up reports not as a
result of user activity' - they just randomly appear? hmmmmmmmm

I think I'd write the application differently. And *not* using HTA!

Pete
--
Peter Wilson
T: 01707 891840
M: 07796 656566
http://www.yellowhawk.co.uk
<http://www.yellowhawk.co.uk>

------------------------------------------------------------------------

[RobG]

Richard Cornford wrote:

RobG wrote:

Raffi wrote:
<snip>

... test page where
we test for popup blockers, ... . This is where
the popup blocker detection script comes into play.

It's even easier than I suspected, ...

<snip>

What is easier than you suspected?

The algorithm that I proposed - attempt to open a new window and have
its presence noted by interacting with the opener. A timer (as I
originally proposed) is not required to implement it, hence 'easier'.
What you have presented is not a -
popup blocker - detector, it is a - NOT popup blocker - detector, but
NOT - NOT popup blocker - is not a - popup blocker -. It may just be a
logical truth, but programming without a regard for logic doesn't tend
to be viable.
Ahhh yeah.

Does 'NOT - NOT ... blocker' count as a triple negative? :-)

All the script does is see if it can successfully open a window and
that the new window has some communication back to the opener. If
that can't be achieved, then the user likely has some form of pop-up
prevention occurring.

No, it is not a rigorous pop-up blocker detector and maybe the
wording of the message to the user should be different, but the OP
seems smart enough to work that out.

My approach more directly addresses the OP's issue, which isn't
really to detect a pop-up blocker per se but to see if pop-ups can be
opened. The presumption may be that the user has employed a blocker
but failure to detect opening a pop-up could be the result of some
other mechanism or factor - including that the users browser does not
support them or that JavaScript is disabled. Hence the wording in the
message should be carefully considered.

zWin = window.open('', ...
<snip>

if (zWin && 'null' != zWin.document){
zWin.document.writeln(hText.join(''));
zWin.document.close();
}

<snip>

Incidentally, some content-inserting/re-writiong proxy style pop-up
blockers return an object from calls to window.open. That object varies
from a reference to the current window (where your script promptly
replaces its contents, removing the option of responding to the result
of the test) to more normal javascript objects (that may or may not
implement a - document - property that is itself an object). Testing
scripts should generally be robust enough not to error-out as they
execute. Much more comprehensive feature testing is called for in this
context.

Yes, no doubt. In no way did I suggest that the sample was
production ready - it was submitted purely as a prototype or proof of
concept. While I didn't say that directly, I think it was obvious
from the context of the posts. Feel free to disagree. :-p

And the comparison with the string 'null' seems inappropriate in any
case.

Richard.

--
Rob

[Raffi]

The main purpose of the popup blocker detection script is to detect if
the user's computer is not allowing popups for whatever reason. We're
not too concerned as to why (JavaScript is checked elsewhere) or by
what software. If there is a popup blocker, we do have instructions on
how to peoperly configure some of the more widely used ones but it's
ultimately the user's responsibility.

The PCs that log into the application are not in a controlled
environment. This is one of the reasons a web based client side
approach was chosen. Since the PCs are in the end user's control, we
are trying to cover as many bases as we can to inform them of why they
are unable to use the application.

RobG, your idea sounds interesting although you can't rely on
window.open not returning anything when the popup is blocked since as
someone else pointed out some blockers return objects even though the
popup is blocked. So a comparison with 'null' indeed doesn't work
reliably. Though your idea of the popup communicating back to the
opener seems to be more reliable in theory.

Thanks,
Raffi

[RobG]

Raffi wrote:

The main purpose of the popup blocker detection script is to detect if
the user's computer is not allowing popups for whatever reason. We're
not too concerned as to why (JavaScript is checked elsewhere) or by
what software. If there is a popup blocker, we do have instructions on
how to peoperly configure some of the more widely used ones but it's
ultimately the user's responsibility.

The PCs that log into the application are not in a controlled
environment. This is one of the reasons a web based client side
approach was chosen. Since the PCs are in the end user's control, we
are trying to cover as many bases as we can to inform them of why they
are unable to use the application.

RobG, your idea sounds interesting although you can't rely on
window.open not returning anything when the popup is blocked since as
someone else pointed out some blockers return objects even though the
popup is blocked. So a comparison with 'null' indeed doesn't work
reliably.
All that is required at that point in the script is to make sure the
attempt to write to the pop-up won't error. Maybe better error
handling/pop-up detection is required - try..catch as a last resort?

If the browser pretends to open a window but doesn't, how do you (as
a script writer) handle that?

The point is not whether your script *thinks* it opened a pop-up, but
whether the user can interact with it - given a suitable scenario, a
browser can't fake that (e.g. make the user do something with the
pop-up - enter some text, click a button, whatever).

If the opener doesn't get a suitable response from the pop-up, it
assumes that the user - can't/didn't/doesn't want to - interact with
the pop-up and displays a message accordingly (covering all the above
cases, maybe more if you're inventive).
Though your idea of the popup communicating back to the
opener seems to be more reliable in theory.

Hence if you combine the pop-up test with login (or some other single
access point), you kill two birds with one script. You test directly
if you can open a pop-up, the user can't proceed without being able
to see/use/interact with pop-ups, and if pop-ups are blocked the user
will see the opener message that (hopefully) helps them muddle
through it all. :-x

All yours!

--
Rob

[Richard Cornford]

RobG wrote:

Richard Cornford wrote: <snip>

What is easier than you suspected?

The algorithm that I proposed - attempt to open a new
window and have its presence noted by interacting with
the opener.

<snip>

But the algorithm you proposed was not a pop-up blocker detector so no
mater how easy it may have been its existence does not modify the
difficulty of creating a pop-up blocker detector.

<snip> All the script does is see if it can successfully open a
window and that the new window has some communication back
to the opener. If that can't be achieved, then the user
likely has some form of pop-up prevention occurring.
You have got your logic back to front again. If that can be performed
then the user likely does not have a pop-up blocker installed. Hence it
is a - NOT pop-up blocker - detector. The step of deducing that NOT a -
NOT pop-up blocker - is a pop-up blcoker is _invalid_.
No, it is not a rigorous pop-up blocker detector
It is not a pop-up blocker detector at all.
and maybe the wording of the message to the user
should be different,
That depends on how much of a fool the author of the text is willing to
be perceived as.
but the OP seems smart enough to work that out.
The OP has failed to observe that any GUI requirements that may be
achieved with pop-up windows can be achieved as effectively without them
(and in some respects more effectively), side-stepping the influence of
pop-up blockers entirely, and negating the issue.
My approach more directly addresses the OP's issue,
which isn't really to detect a pop-up blocker per se
but to see if pop-ups can be opened.
Yes, if the OP's problem is perceived as a need to verify the viability
of their GUI design on the user's browser then running through the
required actions and seeing if they produce the necessary outcome is a
satisfactory solution.

On the other hand re-analysing the OP's stated problem opens the door to
alternative approaches to the entire problem. In practice a web
application is a server with multiple remote GUIs operating on web
browsers, and the interactions between those two. When the GUI
requirements may be achieved with only a single client-side browser
instance the real solution to any pop-up blocker problem may be to stop
trying to open new windows and design the GUI to operate within just
one. Nothing need be lost in such a design, and some things become
considerably simpler (such as modal windows/dialogs, because new browser
instances are not easily rendered modal).

<snip>

... . Much more comprehensive feature testing
is called for in this context.

Yes, no doubt. In no way did I suggest that the
sample was production ready -

Except in not stating that it was not.
it was submitted purely as a prototype or proof
of concept. While I didn't say that directly, I think
it was obvious from the context of the posts. Feel free
to disagree. :-p

<snip>

I do disagree. A partial test presented as doing the opposite of what it
really does is very likely to be taken by people who don't know any
better as some form of 'solution'. One of the reasons that find
ourselves in a situation where people are trying to identify pop-up
blockers is that our environment is full of superficial and inadequate
window opening script examples. Giving the impression that opening new
windows is easy. Inevitably resulting in people doing so, perceiving
doing so as easy, and adopting a mindset where the alternatives seem
complex or unachievable. If example window opening scripts included the
full set of feature and viability testing, and possibly discussed
fall-back strategies, the whole process would be obviously less
appealing.

Incidentally, I neglected to also mention the actions of external pop-up
blockers, which observe the existence of additional browser instances on
the OS and kill them off, externally and asynchronously. Your immediate
approach of getting the new window to assert its opening to its opener
might result in a false positive with such a pop-up blocker. The script
may have finished its whole process prior to an external pop-up blocker
closing the new window. The script would then get the mistaken
impression that the GUI was viable in such an environment (re-enter the
timer).

Richard.