Iframe collision problem
-
This is just wierd. My company makes widgets that get dropped into other people's web sites. Those sites also frequently have a lot of ads.
We use pork.iframe to handle our AJAXy stuff due to some browser quirks with cross-site scripting. For those unfamiliar with pork.iframe, it dynamically adds an iframe to the DOM, submits a form with that iframe as its target, gives the contents of that iframe back to your javascript so it can do what it wants. Basically the same thing as XmlHttpRequest, only with iframes as a transport mechanism.
Our customers' ads also sometimes use iframes. And once in a blue moon, there's a collision. the results of our pork requests end up getting dumped into the ad's iframe as well as ours. So instead of seeing an ad, the user sees our response. I checked the obvious "are both iframes using the same ID?" They're not. ours uses a random number. The ad iframe doesn't even have an id.
Has anybody else seen anything like this?
-
Scripts in iframe'd ads sometimes cause really weird problems. Some have caused firebug to auto-redirect to a void. Anything can happen because of the madness inside, incluing dynamically writing script tags, using js to output js, eval of huge blocks, and utterly convoluted dom solutions.
So have a look there.
-
@dhromed said:
Scripts in iframe'd ads sometimes cause really weird problems. Some have caused firebug to auto-redirect to a void. Anything can happen because of the madness inside, incluing dynamically writing script tags, using js to output js, eval of huge blocks, and utterly convoluted dom solutions.
So have a look there.
Yeah, I had already looked there and it contained all of the above except for crazy dom stuff (which we're happy to provide on my end). The ad starts as a script embed, which then document.writes another script tag, which then document.writes another script tag, which then document.writes some js and the iframe.
Best guess is that this mozilla bug is the culprit, but I have to wait and see whether or not anybody says "I swear I saw it in IE once too" before I can wash my hands of it.
-
@vt_mruhlin said:
The ad starts as a script embed, which then document.writes another script tag, which then document.writes another script tag, which then document.writes some js and the iframe.
I never understood the sense behind this, even though almost all banner ads seem to contain similar complexities. Is this an attempt to fool ad blockers or do the ad networks need the requests to properly manage the ad count?
Does anyone know more about this?
-
@PSWorx said:
Is this an attempt to fool ad blockers or do the ad networks need the requests to properly manage the ad count?
From how it's been described, it appears to be similar to the "why use 5 words when 5 paragraphs/chapters will do."
@PSWorx said:
Does anyone know more about this?
Happily, I don't.
-
I think it's that there are ad producers who make their script, then there are ad resellers who make a script that includes the script tags from various other sources.
That or all the people making banner ads are just morons. I kind of want to go with option 2.
