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.]

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]

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?


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.


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:

[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]

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]

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).

 

[kaeli]

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]

enlightened us with...

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.


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]

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.

--

 

[RobG]

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.

 

[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

 

[RobG]

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.

 

[RobG]

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,menubar=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>

 

[J Wynia]

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]

Raffi wrote:

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('', ...

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]

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]

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/default.asp?url=/workshop/author/hta/overview/htaoverview.asp

 

[Peter Wilson]

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]

<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.

<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.