anti popupkiller code?

**Michael Winter** · Jul 20 '05, 12:40 PM

Re: anti popupkiller code?

me wrote on 09 Dec 2003 at Tue, 09 Dec 2003 23:44:49 GMT:
[color=blue]
> hey all,
> wel i am not talking about the @*&##&$@#)*@)*! @ porn ad
> popupbanner.
>
> I have a page that is a webstore.. normal http://
> when a user want to go to the shopbasket it opens a popup in
> https: ok so far so good.. wel on a special payment type the
> user must follow all 4 steps but when the close at step 3 the
> order is never post to me.. and normal i hed a popupdialog on
> onUnload. i tried even before the shopbasket wash in https with
> a opener.top function that opens the popup dialog but now its
> not possible because of the https domain. ok NOW the ONUNLOAD is
> filters by the popup killers software.. and i hate that.
> its a good thing afcourse because some lameass scripters hed
> overrun the web with porn banners
> but how can i fix this.. i did a trick that works with <body
> onblur="FUNCTIO N">
> but hey :) tha gives in MOZZILA 2 popups???? and when you print
> the page also the dialog window is set.. (popup)[/color]

First of all, intelligent pop-up blockers /cannot/ be beaten, nor
should an author /try/ to do so. No one here should attempt to help
you or anyone else in this endevour.

Secondly, if your page design relies on the presence of JavaScript,
or on the ability to create pop-ups, then it is broken and needs to
be redesigned. If I disabled everything (your style sheets, scripts
and images), I should still be able to use your site effectively.

Blockers are provided for the protection of the user. If the user
wants to block pop-ups, it is their decision to make, not yours and
you should respect that. Besides, there wouldn't be much point in
producing them if their protection can be easily circumvented. Also
be aware that some people will remove *all* pop-ups - even ones that
they request[1], so your onblur 'trick' won't work in all cases.

Mike

In future, please try to check your posts for correct, or at least
easily comprehensible, grammar and spelling. If English isn't your
first language, it might even be better to post in your native
language.

[1] A request in this context is defined as a direct user action
leading to the creation of a new window (an onclick intrinsic event,
for example).

--
Michael Winter
M.Winter@blueyo nder.co.invalid (replace ".invalid" with ".uk")

**Richard Cornford** · Jul 20 '05, 12:40 PM

Re: anti popupkiller code?

"Michael Winter" <M.Winter@bluey onder.co.invali d> wrote in message
news:Xns944DD16 9DB3MWinterBlue yonder@193.38.1 13.46...
<snip>[color=blue]
>First of all, intelligent pop-up blockers /cannot/ be
>beaten,[/color]

If an "intelligen t" pop-up blocker is defined as one that cannot be
beaten then that has to be true, otherwise Yep's demonstration that
content inserting/re-writing proxies acting as pop-up blockers can be
defeated reasonably reliably on most modern browsers may just bring into
question how intelligent it is to use that particular type of pop-up
blocker (especially given browsers with the feature built in).
[color=blue]
>nor should an author /try/ to do so.[/color]

Definitely, especially given the extra design burden of coming up with
both a GUI and a back end that can cope with the possibility that
pop-ups will be allowed and still be functional when they are not.
[color=blue]
>No one here should
>attempt to help you or anyone else in this endevour.[/color]
<snip>

That would depend a bit on which endeavour you are talking about.
Defeating the pop-up blockers certainly deserves no additional help (and
insofar as it can be done the information is already in the archives).

But in the past there has been a strong correlation between people
attempting to do things like this with onunload events and a failure to
properly employ server-side session tracking, so some more general help
might be possible. Unfortunately the OP omits details of that aspect of
the problem. It is unclear as to exactly why the user choosing to close
the shopping cart pop-up (assuming it came into existence in the first
place) is a problem.

This also set me thinking about the order of unload events in pages with
IFRAMEs. I strikes me that, when shutting down a browser, it would be
sensible for the browser to shut down contained frames prior to shutting
down the pages that contained them. So maybe, assuming that onunload
events in contained frames do reliably precede onunload events in the
pages that contain them, it might be possible to use an onunload event
in a contained IFRAME to trigger a sort of imitation onbeforeunload
event for the page that contained it. I have never tested that (I have
only found one valid use of onunload events to date) but it might be
worth a look.

Richard.

me · Jul 20 '05, 12:41 PM

Re: anti popupkiller code?

<snip>
Secondly, if your page design relies on the presence of JavaScript,
or on the ability to create pop-ups, then it is broken and needs to
be redesigned. If I disabled everything (your style sheets, scripts
and images), I should still be able to use your site effectively.
</snip>

Well if you look at the year 2003 you see it is different then 8 years ago.
And if you deside to turn all the Javascript, stylesheets etc off then you
probely wont see 90% of the internet.

A good commerical website comes from the database printen true a serverside
language with no frames and no scriptkiddie stuff.
wel I am a developer for more then 9 years and i can tell you that when a
owner of a webstore with no knowlegde of internet sees at one conc. site
cool stuff (FLASH,DHTML and big designs) he want that too.
so that dont work anymore.. and it the new way of designing.

Ps maybe i would posted in mine own native but who cares!

Cheers.

ps thank you Richard

"Richard Cornford" <Richard@litote s.demon.co.uk> wrote in message
news:br6nak$sl$ 1$8302bc10@news .demon.co.uk...[color=blue]
> "Michael Winter" <M.Winter@bluey onder.co.invali d> wrote in message
> news:Xns944DD16 9DB3MWinterBlue yonder@193.38.1 13.46...
> <snip>[color=green]
> >First of all, intelligent pop-up blockers /cannot/ be
> >beaten,[/color]
>
> If an "intelligen t" pop-up blocker is defined as one that cannot be
> beaten then that has to be true, otherwise Yep's demonstration that
> content inserting/re-writing proxies acting as pop-up blockers can be
> defeated reasonably reliably on most modern browsers may just bring into
> question how intelligent it is to use that particular type of pop-up
> blocker (especially given browsers with the feature built in).
>[color=green]
> >nor should an author /try/ to do so.[/color]
>
> Definitely, especially given the extra design burden of coming up with
> both a GUI and a back end that can cope with the possibility that
> pop-ups will be allowed and still be functional when they are not.
>[color=green]
> >No one here should
> >attempt to help you or anyone else in this endevour.[/color]
> <snip>
>
> That would depend a bit on which endeavour you are talking about.
> Defeating the pop-up blockers certainly deserves no additional help (and
> insofar as it can be done the information is already in the archives).
>
> But in the past there has been a strong correlation between people
> attempting to do things like this with onunload events and a failure to
> properly employ server-side session tracking, so some more general help
> might be possible. Unfortunately the OP omits details of that aspect of
> the problem. It is unclear as to exactly why the user choosing to close
> the shopping cart pop-up (assuming it came into existence in the first
> place) is a problem.
>
> This also set me thinking about the order of unload events in pages with
> IFRAMEs. I strikes me that, when shutting down a browser, it would be
> sensible for the browser to shut down contained frames prior to shutting
> down the pages that contained them. So maybe, assuming that onunload
> events in contained frames do reliably precede onunload events in the
> pages that contain them, it might be possible to use an onunload event
> in a contained IFRAME to trigger a sort of imitation onbeforeunload
> event for the page that contained it. I have never tested that (I have
> only found one valid use of onunload events to date) but it might be
> worth a look.
>
> Richard.
>
>
>[/color]

**Michael Winter** · Jul 20 '05, 12:41 PM

Re: anti popupkiller code?

Richard Cornford wrote on 10 Dec 2003 at Wed, 10 Dec 2003 09:00:02
GMT:
[color=blue]
> "Michael Winter" <M.Winter@bluey onder.co.invali d> wrote in
> message news:Xns944DD16 9DB3MWinterBlue yonder@193.38.1 13.46...
> <snip>[color=green]
>>First of all, intelligent pop-up blockers /cannot/ be
>>beaten,[/color]
>
> If an "intelligen t" pop-up blocker is defined as one that cannot
> be beaten then that has to be true, otherwise Yep's
> demonstration that content inserting/re-writing proxies acting
> as pop-up blockers can be defeated reasonably reliably on most
> modern browsers may just bring into question how intelligent it
> is to use that particular type of pop-up blocker (especially
> given browsers with the feature built in).[/color]

Intelligent probably wasn't the best way of describing what I was
thinking. Something that might fall under the catagory of
'intelligent' wouldn't be fooled by nested functions, eval calls,
etc. All that would really be required, I suppose, is for the
blocker to parse and run the code so that all paths that shouldn't
contain window.open() calls (global scripts, onload/unload events,
interval and timeout events, etc) do, in fact, not.

<snip>
[color=blue][color=green]
>>No one here should attempt to help you or anyone else in this
>>endevour.[/color]
> <snip>
>
> That would depend a bit on which endeavour you are talking
> about. Defeating the pop-up blockers certainly deserves no
> additional help (and insofar as it can be done the information
> is already in the archives).[/color]

The endeavour I was referring to was beating pop-up blockers. As I
said in my earlier post, the user's decision to remove pop-ups is
theirs to make and should be respected. If there are other, unrelated
issues that need attention, then of course, any and all help should
be given.

<snip>

Mike

--
Michael Winter
M.Winter@blueyo nder.co.invalid (replace ".invalid" with ".uk")

**Richard Cornford** · Jul 20 '05, 12:42 PM

Re: anti popupkiller code?

"Michael Winter" <M.Winter@bluey onder.co.invali d> wrote in message
news:Xns944DB71 58935EMWinterBl ueyonder@193.38 .113.46...
<snip>[color=blue]
>... . All that would really be required, I suppose, is for
>the blocker to parse and run the code so that all paths
>that shouldn't contain window.open() calls (global scripts,
>onload/unload events, interval and timeout events, etc) do,
>in fact, not.[/color]
<snip>

That is a fairly big "All". I am yet to see an external pop-up blocker
that even attempt that. Of course the browsers that have the facility
built in have to parse and run the code anyway (and provide a DOM for it
to interact with) so for them monitoring the context in which calls to
window.open occur is much easier.

Richard.

anti popupkiller code?

anti popupkiller code?

Comment

Comment

Comment

Comment

Comment