No access to variables in parent document

Hi,

I have an index.html with a frameset with 2 php files. The top frame are
buttons, that refresh the lower frame or put different content in it.
Some of these pages have javascript-tabs and I keep the current tab in
an array in the parent document:

window.parent.curTab[window.location] = elNewTab;

elNewTab is the <div> element that is shown.

This works fine, with no errors in Firefox 2. However, if I try to run
it in IE7, I get 'Permission denied' errors (I installed DebugBar).
Apparently, writing the window.parent.curTab array is no problem, but
reading it is not allowed.

I tried to change the browser security settings (the site is in 'trusted
sites' now), to no avail.

Any help?

Bart Friederichs

On Jun 9, 4:12 pm, Bart Friederichs <b... (AT) tbwb (DOT) nospam.nl> wrote:

Hi,

I have an index.html with a frameset with 2 php files. The top frame are
buttons, that refresh the lower frame or put different content in it.
Some of these pages have javascript-tabs and I keep the current tab in
an array in the parent document:

window.parent.curTab[window.location] = elNewTab;

elNewTab is the <div> element that is shown.

This works fine, with no errors in Firefox 2. However, if I try to run
it in IE7, I get 'Permission denied' errors (I installed DebugBar).
Apparently, writing the window.parent.curTab array is no problem, but
reading it is not allowed.
Are you saying that you can CHANGE the values in the

window.parent.curTab, but you can NOT read it back?
If so, then it is definitely a bug in IE7. This may be to do with
prevention of "cross-site-scripting"

I tried to change the browser security settings (the site is in 'trusted
sites' now), to no avail.
So, it has nothing to do with your security settings.

Any help?

Bart Friederichs

GArlington wrote:

Are you saying that you can CHANGE the values in the
window.parent.curTab, but you can NOT read it back?

Well. It's hard to know for sure that I can write them, because I cannot
read them. The 'access denied' occurs when trying to read, not when
trying to write.

My next try is to put these variables in the DOM, hoping I can
manipulate that.

Bart

Bart Friederichs wrote:

GArlington wrote:
Are you saying that you can CHANGE the values in the
window.parent.curTab, but you can NOT read it back?

Well. It's hard to know for sure that I can write them, because I cannot
read them. The 'access denied' occurs when trying to read, not when
trying to write.

Chances are that your attempts at write access are silently blocked.

My next try is to put these variables in the DOM, hoping I can
manipulate that.

IIUC, you should not do that. Host objects need not to allow augmentation.
We discussed this several times already.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7 (AT) news (DOT) demon.co.uk>

Thomas 'PointedEars' Lahn wrote:

Chances are that your attempts at write access are silently blocked.

How to fix this problem then? Are there any solutions to 'register' some
variables in the top frameset? Cookies?

IIUC, you should not do that. Host objects need not to allow augmentation.
We discussed this several times already.

Well, if I had XHTML, and registered a new namespace, I can put anything
I like in the DOM. However, I have to support IE and IE doesn't support
XHTML correctly, so that's not a viable solution.

Bart

Bart Friederichs wrote:

Well, if I had XHTML, and registered a new namespace, I can put anything
I like in the DOM. However, I have to support IE and IE doesn't support
XHTML correctly, so that's not a viable solution.

The solution I found was the following:

In the frame that stays available at all times (my navigation bar), I
registered the values in the 'name' attribute of a button. Works both in
IE and Fx. I know it is attribute-abuse, but completely rebuilding my
app takes way more time (and thus money).

Bart

Bart Friederichs wrote:

Thomas 'PointedEars' Lahn wrote:
Chances are that your attempts at write access are silently blocked.

How to fix this problem then? Are there any solutions to 'register' some
variables in the top frameset? Cookies?

I don't think you can "fix" this "problem" other than with transparent
server-side URL rewrite.

IIUC, you should not do that. Host objects need not to allow augmentation.
We discussed this several times already.

Well, if I had XHTML, and registered a new namespace, I can put anything
I like in the DOM.

You could not (and you would not need a new namespace for that). There is a
difference between properties of an (host) object and the attributes of the
element it represents. The DOM Specification for XHTML 1.0 documents and
elements is W3C DOM Level 2 HTML and it would be prudent to adhere to that.

However, you could probably set a properly declared user-defined attribute
of the element and read its value back. But you should not assume that just
because it is XHTML you can augment host element objects arbitrarily.

<LRN>With host objects, all bets are off.</LRN>

However, I have to support IE and IE doesn't support
XHTML correctly, so that's not a viable solution.

As I have said before, what you are trying is not viable either.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7 (AT) news (DOT) demon.co.uk>

Bart Friederichs wrote:

Bart Friederichs wrote:
Well, if I had XHTML, and registered a new namespace, I can put anything
I like in the DOM. However, I have to support IE and IE doesn't support
XHTML correctly, so that's not a viable solution.

The solution I found was the following:

In the frame that stays available at all times (my navigation bar), I
registered the values in the 'name' attribute of a button. Works both in
IE and Fx. I know it is attribute-abuse, but completely rebuilding my
app takes way more time (and thus money).

You should use the `value' property of an object that represents an
<input type="hidden" ...> element instead. Making that the descendant
of a `form' element would be prudent, this way you could access it using
backwards-compatible standards-compliant HTMLCollection references.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7 (AT) news (DOT) demon.co.uk>

Thomas 'PointedEars' Lahn wrote:

You could not (and you would not need a new namespace for that). There is a
difference between properties of an (host) object and the attributes of the
element it represents. The DOM Specification for XHTML 1.0 documents and
elements is W3C DOM Level 2 HTML and it would be prudent to adhere to that.

Euh, as I understood it, XHTML is pure XML and there is nothing stopping
me to register a new namespace (could do that server side) and mixing
XHTML and whatever I can think of (some self-defined XML). That is
actually one of the powers of XML, and thus of XHTML (i.e. embedding SVG
in XHTML without needing a seperate file).

Bart

Bart Friederichs wrote:

Thomas 'PointedEars' Lahn wrote:
You could not (and you would not need a new namespace for that). There is a
difference between properties of an (host) object and the attributes of the
element it represents. The DOM Specification for XHTML 1.0 documents and
elements is W3C DOM Level 2 HTML and it would be prudent to adhere to that.

Euh, as I understood it, XHTML is pure XML and there is nothing stopping
me to register a new namespace (could do that server side) and mixing
XHTML and whatever I can think of (some self-defined XML). That is
actually one of the powers of XML, and thus of XHTML (i.e. embedding SVG
in XHTML without needing a seperate file).

You are mistaken. Please read my posting, more thoroughly this time, again.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee