Firefox bug with Document.Domain

[Startuppk]

The following code for some reason does not work in Firefox 2.x. It
does work however in IE and Opera.

The code is found within an iframe and I am trying to access the
document object of the parent without success in Firefox.

The parent document is located at http://mysite.com (domain is
mysite.com)
The iframe document is located at http://images.mysite.com (I have
used javascript to set the domain to mysite.com)

iFrame Code :

<script language="javascript">

document.domain = "mysite.com";

var par = window.parent.document;

par.getElementById('alert_user').innerHTML = "Select an image";

</script>

The script basically stops when it hits the par.getElement line in
Firefox.

Any help with issue would be appreciated,

 

[Stevo]

The following code for some reason does not work in Firefox 2.x. It
does work however in IE and Opera.

<script language="javascript">
document.domain = "mysite.com";
var par = window.parent.document;
par.getElementById('alert_user').innerHTML = "Select an image";
</script>
The script basically stops when it hits the par.getElement line in
Firefox.

It doesn't just stop though does it. It tells you what it's unhappy
about in the Error Console.

I've done this exact same thing before and it's worked just fine in
Firefox. I don't see anything you're doing differently.

You might want to try (just as a test) doing your getElementById there
after a setTimeout of 5 seconds. That'll tell you whether it's a timing
issue. If that works, then you might have to split up a function into
two parts. I've got some JS that I need to go and do that too (after
Randy Webb suggested it to me). In my case though, I'm "creating" the
code in the parent page from the iframe, and then trying to call it
immediately and it's just not ready to do so. When I put the call I was
trying to make in a setTimeout call (so that it happened later, instead
of immediately) then it worked just fine.

You're changing your domain and then immediately trying to take
advantage of that, and maybe the parent just hasn't noticed (yet) that
you've done that.

 

[Thomas 'PointedEars' Lahn]

The parent document is located at http://mysite.com (domain is
mysite.com)
The iframe document is located at http://images.mysite.com (I have
used javascript to set the domain to mysite.com)

iFrame Code :

<script language="javascript"> ^^^^^^^^^^^^^^^^^^^^^^
document.domain = "mysite.com";

var par = window.parent.document;

par.getElementById('alert_user').innerHTML = "Select an image";

Don't use `innerHTML', especially not in such a reference worm.

http://www.jibbering.com/faq/faq_notes/not_browser_detect.html

</script>

The script basically stops when it hits the par.getElement line in
Firefox.

Probably it does more. Type

javascript:

in the location bar, or <http://getfirebug.com/>.

Try

var par = window.parent;
... par.document.getElementById('alert_user') ...

Any help with issue would be appreciated,

Start with validating your markup: <http://validator.w3.org/>


PointedEars

 

[Stevo]

^^^^^^^^^^^^^^^^^^^^^^

Yeah, you have to stop using this because it works on all browsers
without problems.

Don't use `innerHTML', especially not in such a reference worm.
http://www.jibbering.com/faq/faq_notes/not_browser_detect.html

Don't use innerHTML either. It's too easy, and ignore the recommendation
to use it inside that FAQ document also.

 

[David Mark]

Yeah, you have to stop using this because it works on all browsers
without problems.

It is a deprecated attribute. Use type="text/javascript" or nothing.
Those work in all browsers too. Furthermore, this works in all
browsers without problems:

<script invalid="invalid">

Would you advocate using that?

Don't use innerHTML either. It's too easy, and ignore the recommendation

It is a non-standard property, has known issues and is virtually never
needed. The OP is referencing that property, which may not be
supported, on an object that may or may not exist at the time of the
reference.

to use it inside that FAQ document also.

Where does the FAQ recommend using innerHTML? If you mean DynWrite,
that is just an example of how to simulate document.write after a page
has loaded. It does not recommend designing applications that rely on
such a thing.

 

[Stevo]

It is a deprecated attribute. Use type="text/javascript" or nothing.
Those work in all browsers too. Furthermore, this works in all
browsers without problems:

Yes, that's what I said too. To quote myself "you have to stop using
this". It's certainly not a reason why the OP's code isn't working though.

<script invalid="invalid">
Would you advocate using that?

No, it's not valid and never has been. Something that's deprecated like
language=javascript is still valid.

Where does the FAQ recommend using innerHTML? If you mean DynWrite,

Here's a quote from it (with a few ~~ to shorten it):

The document.write method is not the only way of adding GUI components
to a web page ~~ Alternatives include ~~ innerHTML property ~~ or using
the W3C DOM document.crateElement

That's my favourite method ... "crateElement"

 

[Startuppk]

I looked at the Javascript errors in Firefox and found the following
exception ...

Error: uncaught exception: Permission denied to get property
HTMLDocument.getElementByID

I changed <script language="javascript"> to <script>
I also replaced the innerHTML line
par.getElementById('alert_user').innerHTML = "Select an image";
with par.getElementById('alert_user').style.background = "#FFF";

Still got the Permission denied message.

 

[Startuppk]

I was able to fix the "bug" by placing a <script>document.domain =
"mysite.com";</script> in the parent http://mysite.com html file, even
though the domain should have already been mysite.com by default.
Thanks for everyone's suggestions.

 

[David Mark]

Yes, that's what I said too. To quote myself "you have to stop using
this". It's certainly not a reason why the OP's code isn't working though.

You didn't quote the rest of your comment, which was clearly
sarcastic. And clearly it isn't the reason the code isn't working.

No, it's not valid and never has been. Something that's deprecated like
language=javascript is still valid.

Depends on the doctype.

Here's a quote from it (with a few ~~ to shorten it):

The document.write method is not the only way of adding GUI components
to a web page ~~ Alternatives include ~~ innerHTML property ~~ or using
the W3C DOM document.crateElement

It doesn't indicate that one is recommended over the other.

That's my favourite method ... "crateElement"

I think the proper way to report such a typo is to include <FAQENTRY>
in the message.

 

[Dr J R Stockton]

In comp.lang.javascript message <ef5438d2-6d39-44a4-be5d-9b9a99d2499c@w4
0g2000hsb.googlegroups.com>, Sun, 9 Dec 2007 13:20:49, David Mark

Where does the FAQ recommend using innerHTML? If you mean DynWrite,
that is just an example of how to simulate document.write after a page
has loaded. It does not recommend designing applications that rely on
such a thing.

If you could provide a substitute for DynWrite using DOM methods,
perhaps Randy would put it into the FAQ.

But ISTM that it should not need (or always need) createElement, as
DynWrite can be used repeatedly on the same ID replacing the content
each time.

 

[Stevo]

Where does the FAQ recommend using innerHTML? If you mean DynWrite,
that is just an example of how to simulate document.write after a page
has loaded. It does not recommend designing applications that rely on
such a thing.

Why would the FAQ tell you about a feature, explain how to use it, give
an example block of code, but not recommend you rely on it?

It's not treated the same way eval is. The description for eval starts
with "The eval() function should only be used when it is necessary ...."

The description for DynWrite says nothing negative about it at all other
than it's non-standard. It's such wide use that makes things become
standard, and I'd argue that it is standard now in the fact that it's
commonplace. Lots of standards evolve that way. I don't know of a
browser with more than 0.1% share of the browser market that doesn't
support it. That pretty much makes it standard. If you were releasing a
new browser, would you not support it? By the 14th second of the public
beta you'd be inundated with emails about sites that don't work and
you'd have to change your plans.

In fact in answer to the FAQ question "How do I modify the current page
in a browser? ", there is only one suggestion and that's innerHTML.

IMHO It's time we stop telling people to not use it.

</soapbox>

 

[David Mark]

In comp.lang.javascript message <ef5438d2-6d39-44a4-be5d-9b9a99d2499c@w4
0g2000hsb.googlegroups.com>, Sun, 9 Dec 2007 13:20:49, David Mark
<[email protected]> posted:




If you could provide a substitute for DynWrite using DOM methods,
perhaps Randy would put it into the FAQ.

I could, but it would need to be a slightly different design (i.e. the
parameter passed would not be a string.)

But ISTM that it should not need (or always need) createElement, as
DynWrite can be used repeatedly on the same ID replacing the content
each time.

Passed a reference to an element object, a similar function can remove
all children of the target element and replace them with copies of the
children of the passed object. That is how I do Ajax updates in XHTML
documents. The function has to use createElement to copy the children
as you can't append elements from one document to another and
importNode has issues that limit its effectiveness as an innerHTML
substitute.

Granted, this is not the same dynamic document.write replacement as
presented by the FAQ's example. My main point is that such an example
is rarely needed in practice.

 

[David Mark]

DynWrite, as in the group FAQ, is *not* a "document.write replacement".
It is nowhere even close to that and has *never* been intended as
anything remotely close to a document.write replacement.

The key word was "dynamic." As in, it can be used to similar things
after the page has loaded. Replacement was the wrong word.

Is the "example" you refer to the use of innerHTML or something else?

I refer to the fact that I have never found the need to use such a
function.

 

[Dr J R Stockton]

In comp.lang.javascript message <129f2ee4-f194-4cce-b370-3b4b2ea6ee93@b1
g2000pra.googlegroups.com>, Mon, 10 Dec 2007 13:17:25, David Mark

I could, but it would need to be a slightly different design (i.e. the
parameter passed would not be a string.)

The call DynWrite(ID, string) expresses exactly what is often wanted.
You might choose to provide a routine for replacing the content of an ID
with a more general item or items, and such a routine could be more
widely used; but in that case it should be easy to put string-to-item
and your more general routine together in something with the same
parameters as DynWrite.

One should be able to replace all existing calls of DynWrite by just
changing the function name; but it would be acceptable to allow any
positive number of parameters of any type, provided that (ID, string)
remained permissible.

I've replaced DynWrite(ID, string) with Wryt(ID, string) in my pages.