Cross-frame location.reload ()

[permanent.tourist]

I'm having a hell of a job getting this to work in Safari: the only
thing I can think of is that one can't use reload() across to another
frame for security reasons. Does anyone have a concrete answer or
solution for this? I'm trying to do this:

top.frames["mainConten t"].location.reloa d();

Thanks
Mark Howells
www.permanenttourist.ch

[Thomas 'PointedEars' Lahn]

pe************* **@gmail.com wrote:
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^
Your name would be appreciated here.

I'm having a hell of a job getting this to work in Safari: the only
thing I can think of is that one can't use reload() across to another
frame for security reasons.
One usually can if the second-level domain of both resources is the same.
This security measure is not restricted to Safari. Search the archives for
"Same Origin Policy".
Does anyone have a concrete answer or solution for this?
Use `document.domai n' if both resources are within the same second-level
domain. Use server-side redirection if they do not, or if `document.domai n'
does not help for other reasons.
I'm trying to do this:

top.frames["mainConten t"].location.reloa d();
A line of code that is syntactically and semantically correct (lacking
feature tests, but these are features of DOM Level 0, and therefore testing
them is maybe negligible), yet completely useless for problem analysis as
you are not saying what resource tries to access what other resource.
[...]

No ads, please.
PointedEars

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 3/14/2006 6:26 AM:

pe************* **@gmail.com wrote:
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^
Your name would be appreciated here.

So you have changed from being pedantic about valid email addresses to
requesting/requiring a name? There is *nothing* that says anything about
giving a name.

[...]

No ads, please.

That wasn't an ad, it was a signature. Sheesh.
But go ahead, say the same thing about mine.
--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Thomas 'PointedEars' Lahn]

Randy Webb wrote:

Thomas 'PointedEars' Lahn said the following on 3/14/2006 6:26 AM:

[...]

No ads, please.

That wasn't an ad, it was a signature. Sheesh.
But go ahead, say the same thing about mine.

You silly sod, there was no signature in his posting, in contrast to yours.
That is why I saw your signature delimited from the rest by a nice grey
line when reading, and it "magically" disappeared from your posting when
the editor window for this followup opened ...

May Ctrl+U be with you.
HTH & HAND

PointedEars

[Mark Howells]

> Your name would be appreciated here.

I updated my profile after writing, apologies to all.

I'm having a hell of a job getting this to work in Safari: the only
thing I can think of is that one can't use reload() across to another
frame for security reasons.

One usually can if the second-level domain of both resources is the same.
This security measure is not restricted to Safari. Search the archives for
"Same Origin Policy".

It has nothing to do with cross-domain scripting, it's just accessing
one frame from another. The problem is only evident in Safari and is
almost certainly to do with client-side security (connected to remote
window blocking and so forth?).

Does anyone have a concrete answer or solution for this?
[snip]
I'm trying to do this:

top.frames["mainConten t"].location.reloa d();

I've received a suggestion directly off-group in the meantime, which is
a bit of a hack but which seems to work cross-browser and
cross-platform:

top.frames['mainContent'].location.searc h +=
(top.frames['mainContent'].location.searc h ? '&' : '?' ) + 'rand=' +
Math.random();

Regards
Mark Howells
www.permanenttourist.ch

[Mark Howells]

So, what's the difference between Randy's signature line and mine.
(Apart from the lyrics!)

Regards
Mark Howells
www.permanenttourist.ch

[Thomas 'PointedEars' Lahn]

Mark Howells wrote:

Please provide attribution of quoted material.
In Google Groups: show options, Reply.
vvvvvvvvvvvvvvv vvvvvvvvvvvvvvv vvvvvvvv

Your name would be appreciated here.

> I'm having a hell of a job getting this to work in Safari: the only
> thing I can think of is that one can't use reload() across to another
> frame for security reasons. One usually can if the second-level domain of both resources is the same.
This security measure is not restricted to Safari. Search the archives
for "Same Origin Policy".

It has nothing to do with cross-domain scripting, it's just accessing
one frame from another. The problem is only evident in Safari and is
almost certainly to do with client-side security (connected to remote
window blocking and so forth?).

Is there a setting for another security measure regarding window-to-window
access in Safari one should be aware of, or is this merely your assumption?
If the former, is there any error message if you attempt the former, is
there any documentation about this feature? Because I have never heard of
this before.

> Does anyone have a concrete answer or solution for this?
> I'm trying to do this:
>
> top.frames["mainConten t"].location.reloa d();

I've received a suggestion directly off-group in the meantime,
which is a bit of a hack but which seems to work cross-browser
and cross-platform:

And eating away local cache space.
top.frames['mainContent'].location.searc h +=
(top.frames['mainContent'].location.searc h ? '&' : '?' ) + 'rand=' +
Math.random();

I think you ran into a caching problem instead, which is "solved" by this
nonsense. If that is the case, it would be better solved with using
cache-controlling headers.
PointedEars

[Randy Webb]

Mark Howells said the following on 3/14/2006 7:39 AM:

Please quote what you are replying to.

If you want to post a followup via groups.google.c om, don't use the
"Reply" link at the bottom of the article. Click on "show options" at
the top of the article, then click on the "Reply" at the bottom of the
article headers.

<URL: http://www.safalra.com/special/googlegroupsreply/ >

So, what's the difference between Randy's signature line and mine.
(Apart from the lyrics!)
The major difference? Mine starts dash dash space followed by the
signature. The impact? When most decent newsreaders quote a post, it
will strip off a delimited signature starting with the dash dash space.
So, when Thomas replies to me, it removes my signature automatically.
When he, or I, reply to yours, it quotes it instead without removing it.

The minor difference? Thomas decided yours didn't fit his "requiremen ts"
so he got pedantic about it. Ignore his pedantics.
Regards
Mark Howells
www.permanenttourist.ch

I am not sure if Google Groups allows you to save a signature line. If
it does, simply add -- followed by a space on a line of it's own and
save it.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 3/14/2006 6:43 AM:

Randy Webb wrote:

Thomas 'PointedEars' Lahn said the following on 3/14/2006 6:26 AM:

[...]
No ads, please. That wasn't an ad, it was a signature. Sheesh.
But go ahead, say the same thing about mine.

You silly sod, there was no signature in his posting, in contrast to yours.

Yes there was. It may not be a "properly delimited signature" but it's
still a signature.
That is why I saw your signature delimited from the rest by a nice grey
line when reading, and it "magically" disappeared from your posting when
the editor window for this followup opened ...
Nice grey line? Where? I see no grey line and didn't put it there. But
for what it's worth, I see signatures as bright blue not grey.
May Ctrl+U be with you.

Nah, Ctrl+K is more fun.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Mark Howells]

Thomas 'PointedEars' Lahn wrote:

Mark Howells wrote:

Please provide attribution of quoted material.
In Google Groups: show options, Reply.
vvvvvvvvvvvvvvv vvvvvvvvvvvvvvv vvvvvvvv

Your name would be appreciated here.
> I'm having a hell of a job getting this to work in Safari: the only
> thing I can think of is that one can't use reload() across to another
> frame for security reasons.
One usually can if the second-level domain of both resources is the same.
This security measure is not restricted to Safari. Search the archives
for "Same Origin Policy".

It has nothing to do with cross-domain scripting, it's just accessing
one frame from another. The problem is only evident in Safari and is
almost certainly to do with client-side security (connected to remote
window blocking and so forth?).

Is there a setting for another security measure regarding window-to-window
access in Safari one should be aware of, or is this merely your assumption?
If the former, is there any error message if you attempt the former, is
there any documentation about this feature? Because I have never heard of
this before.

> Does anyone have a concrete answer or solution for this?
> I'm trying to do this:
>
> top.frames["mainConten t"].location.reloa d();

I've received a suggestion directly off-group in the meantime,
which is a bit of a hack but which seems to work cross-browser
and cross-platform:

And eating away local cache space.

top.frames['mainContent'].location.searc h +=
(top.frames['mainContent'].location.searc h ? '&' : '?' ) + 'rand=' +
Math.random();

I think you ran into a caching problem instead, which is "solved" by this
nonsense. If that is the case, it would be better solved with using
cache-controlling headers.
PointedEars

No, there are no further settings for cross-frame security in Safari,
but there are a huge amount of Javascript issues that I run into every
day in this browser, which have to be worked around or accepted as
errors or bad decisions in the browser JS implementation. A particular
problem is over-aggressive caching of pages and Javascript variable
values, which have been a problem since the first betas were released.

In this case, it's not possible that the problem is due to caching, as
the reload() function is never even activated by the browser, despite
being called. That means, to be clear, that the page I'm trying to
reload doesn't get reloaded, not that it's aggressively cached. It
doesn't get re-requested at all unless I use the location.search method
indicated above. Perhaps my previous emails weren't clear enough for
you to understand the problem; in which case, I apologize.

As to the flood of "how-to" replies in this thread: is this usual for a
Usenet group? I've never come across so many rules and regulations
before!

--
Regards
Mark Howells
www.permanenttourist.ch