Popup Blocker Detection

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

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!

 

[Richard Cornford]

Richard Cornford wrote:

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.

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

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.

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