By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,818 Members | 2,089 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,818 IT Pros & Developers. It's quick & easy.

anti popupkiller code?

P: n/a
me
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="FUNCTION">
but hey :) tha gives in MOZZILA 2 popups???? and when you print the page
also the dialog window is set.. (popup)

any idea's?

:(

Cheers,

ME
--
_________________________________________
k zobra
ICQ#: 97557460
More ways to contact me: http://wwp.icq.com/97557460
_________________________________________
Jul 20 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
me wrote on 09 Dec 2003 at Tue, 09 Dec 2003 23:44:49 GMT:
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="FUNCTION">
but hey :) tha gives in MOZZILA 2 popups???? and when you print
the page also the dialog window is set.. (popup)


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.******@blueyonder.co.invalid (replace ".invalid" with ".uk")
Jul 20 '05 #2

P: n/a
"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:Xn*****************************@193.38.113.46 ...
<snip>
First of all, intelligent pop-up blockers /cannot/ be
beaten,
If an "intelligent" 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).
nor should an author /try/ to do so.
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.
No one here should
attempt to help you or anyone else in this endevour.

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

Jul 20 '05 #3

P: n/a
me
<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" <Ri*****@litotes.demon.co.uk> wrote in message
news:br******************@news.demon.co.uk...
"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:Xn*****************************@193.38.113.46 ...
<snip>
First of all, intelligent pop-up blockers /cannot/ be
beaten,


If an "intelligent" 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).
nor should an author /try/ to do so.


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.
No one here should
attempt to help you or anyone else in this endevour.

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

Jul 20 '05 #4

P: n/a
Richard Cornford wrote on 10 Dec 2003 at Wed, 10 Dec 2003 09:00:02
GMT:
"Michael Winter" <M.******@blueyonder.co.invalid> wrote in
message news:Xn*****************************@193.38.113.46 ...
<snip>
First of all, intelligent pop-up blockers /cannot/ be
beaten,


If an "intelligent" 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).


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>
No one here should attempt to help you or anyone else in this
endevour.

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


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.******@blueyonder.co.invalid (replace ".invalid" with ".uk")
Jul 20 '05 #5

P: n/a
"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:Xn*******************************@193.38.113. 46...
<snip>
... . 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>

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.
Jul 20 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.