unintended reloading of iframe over google image result pag
Posted: Sat Aug 24, 2013 4:15 am
This happens when I search at images.google.com
for images of "Jes Macallan" and click on one of the
results from zimbio.com ; most of the other source
pages cause no "surprises" .
I originally wrote this problem description about 2
months ago , but things haven't changed ... even
though both Firefox and noScript versions have .
In these cases , NEITHER google.com NOR zimbio.com
has my permission to execute scripts in noScript .
And I have checked "warn me when websites try to redirect ..."
on the Firefox ( Tools | Advanced | General ) tab ...
So I EXPECT that no automatic reloading will occur .
However , sometimes it does ...
I should note here that most users have google.com
among their trusted sites ; I usually do not ...
The behaviors described here are specifically for
the case when google.com is NOT a trusted site ...
A typical google image "search result" (below is part of
the URL , split apart , for one google image result)
http://www.google.com/imgres?
imgurl=http://www3.pictures.zimbio.com/mp/qWVVE09tig5c.jpg
&imgrefurl=http://www.zimbio.com/Jes%2BMacallan
... (the FULL URL was at the bottom of this message
but it tripped your spam-filter and I had to remove it)
Below (I think) is the google HTML loading the zimbio
source page containing the image ...
<iframe src="http://www.zimbio.com/Jes+Macallan"
id=il_f frameborder=0></iframe>
And below (I think) is the zimbio code that quickly reloads
their iframed-page OVER the intended "google result" page
<script type="text/javascript">
if (window.self != window.top){top.location.replace(window.location.pathname);}
var Timer = {s: (new Date().getTime()),Stack: {},add: function(n){Timer.Stack[n] = new Date().getTime() - Timer.s;}
};
</script>
There is no "warning message" ... it just "happens" .
The same behavior is seen with noScript 2.668 in Firefox 22.0 ,
and with noScript 2.6.7.1 in Firefox 23.0.1 ... which is my
current software .
The same mis-behavior also occurs with allstarpics.net
which uses this script code in the html of its page :
<script type="text/javascript">
if (window.self != window.top)
{top.location.replace(window.location.pathname);}</script>
Is this the correct behavior of the browser under the
conditions I chose ? Is there another option box to
check ... in order to BLOCK "top-loading" of <iframes> ?
IF I turn off iframes (it is on by default) , I get
just a warning in the iframe space with NO content ,
so I turned it back ON ...
Also , I'm not certain Firefox is doing exactly
what its designers intended with <iframes> ... For
instance , choosing ( View Image ) on the right-mouse
menu while hovering over an image in the iframe , you
still get the ability to toggle between the image fit
into the iframe , and the full-size image with scroll
bars in the iframe ; but the little circle with the
(+) or (-) doesn't appear (like it does in the "main"
page , with the view image option) . So , this may
be an irrelevant observation , or evidence that some
features are not fully implemented in iframes with
Firefox 22.0 or 23 ...
I should have mentioned it before , but I am using
Windows XP sp3 , patched up to date as of Aug 15 ,
with the free "security essentials" from Microsoft .
My PC is a 2005 Dell model gx620 with 4gB ram and
a 3gHz dual-core Intel processor . I have turned
off "virtual memory" (using only physical ram) in
the Windows system , and I keep an eye on memory
usage , myself . The c: drive has 50gB free ...
Otherwise , my setup is probably not unusual .
Before submitting this note I searched over a month
ago in google for this
"top.location" iframe script site:forums.informaction.com
and found only 2 (unrelated) discussions .
Currently , this search request produces no result .
I hope this is adequate searching before reporting a
"problem" ... which may just be my own uninformed
use of the software . With my apologies , if so .
I realize that this behavior is not , by itself ,
a hazard for users , but it may still indicate
a bug , either in noScript or Firefox .
Any advice or help the forum can provide will
be appreciated ... Thanks . Mark
for images of "Jes Macallan" and click on one of the
results from zimbio.com ; most of the other source
pages cause no "surprises" .
I originally wrote this problem description about 2
months ago , but things haven't changed ... even
though both Firefox and noScript versions have .
In these cases , NEITHER google.com NOR zimbio.com
has my permission to execute scripts in noScript .
And I have checked "warn me when websites try to redirect ..."
on the Firefox ( Tools | Advanced | General ) tab ...
So I EXPECT that no automatic reloading will occur .
However , sometimes it does ...
I should note here that most users have google.com
among their trusted sites ; I usually do not ...
The behaviors described here are specifically for
the case when google.com is NOT a trusted site ...
A typical google image "search result" (below is part of
the URL , split apart , for one google image result)
http://www.google.com/imgres?
imgurl=http://www3.pictures.zimbio.com/mp/qWVVE09tig5c.jpg
&imgrefurl=http://www.zimbio.com/Jes%2BMacallan
... (the FULL URL was at the bottom of this message
but it tripped your spam-filter and I had to remove it)
Below (I think) is the google HTML loading the zimbio
source page containing the image ...
<iframe src="http://www.zimbio.com/Jes+Macallan"
id=il_f frameborder=0></iframe>
And below (I think) is the zimbio code that quickly reloads
their iframed-page OVER the intended "google result" page
<script type="text/javascript">
if (window.self != window.top){top.location.replace(window.location.pathname);}
var Timer = {s: (new Date().getTime()),Stack: {},add: function(n){Timer.Stack[n] = new Date().getTime() - Timer.s;}
};
</script>
There is no "warning message" ... it just "happens" .
The same behavior is seen with noScript 2.668 in Firefox 22.0 ,
and with noScript 2.6.7.1 in Firefox 23.0.1 ... which is my
current software .
The same mis-behavior also occurs with allstarpics.net
which uses this script code in the html of its page :
<script type="text/javascript">
if (window.self != window.top)
{top.location.replace(window.location.pathname);}</script>
Is this the correct behavior of the browser under the
conditions I chose ? Is there another option box to
check ... in order to BLOCK "top-loading" of <iframes> ?
IF I turn off iframes (it is on by default) , I get
just a warning in the iframe space with NO content ,
so I turned it back ON ...
Also , I'm not certain Firefox is doing exactly
what its designers intended with <iframes> ... For
instance , choosing ( View Image ) on the right-mouse
menu while hovering over an image in the iframe , you
still get the ability to toggle between the image fit
into the iframe , and the full-size image with scroll
bars in the iframe ; but the little circle with the
(+) or (-) doesn't appear (like it does in the "main"
page , with the view image option) . So , this may
be an irrelevant observation , or evidence that some
features are not fully implemented in iframes with
Firefox 22.0 or 23 ...
I should have mentioned it before , but I am using
Windows XP sp3 , patched up to date as of Aug 15 ,
with the free "security essentials" from Microsoft .
My PC is a 2005 Dell model gx620 with 4gB ram and
a 3gHz dual-core Intel processor . I have turned
off "virtual memory" (using only physical ram) in
the Windows system , and I keep an eye on memory
usage , myself . The c: drive has 50gB free ...
Otherwise , my setup is probably not unusual .
Before submitting this note I searched over a month
ago in google for this
"top.location" iframe script site:forums.informaction.com
and found only 2 (unrelated) discussions .
Currently , this search request produces no result .
I hope this is adequate searching before reporting a
"problem" ... which may just be my own uninformed
use of the software . With my apologies , if so .
I realize that this behavior is not , by itself ,
a hazard for users , but it may still indicate
a bug , either in noScript or Firefox .
Any advice or help the forum can provide will
be appreciated ... Thanks . Mark