283389 - script not found even though copied from child document to parent document

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[AJS]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)

The testcase is self-evident.  THe bug reproduces on Firefox, but not on IE.  
Basically, I am dynamically loading the BODY of a child document into a DIV in 
the parent document, using a hidden iframe.  The purpose of this is to do page 
assembly within the browser (content from different sources is loaded into 
iframes; as each is loaded, it gets copied into the main [parent] document).



Reproducible: Always

Steps to Reproduce:
1. Go to http://www.geocities.com/asefkow/frames/parent.htm
2. Click the link in step (1)
3. Once the DIV is filled, click the link inside the DIV (blue box).

Actual Results:  
On IE, you get the alert.  On Firefox, you do not.  Looking at the Javascript 
console, it says that the showAlert() function could not be found.  However, 
it was copied from the iframe, along with the body html.


Expected Results:  
I should see the alert.

Comment 1

[Ben Fowler]

Could you review Bug 282573 "Element created in a page from popup can't open 
popup" and report back whether you are using innerHTML and/or whether the
work around there is of any use.

Comment 2

[AJS]

Ben, thanks for the cross-reference.  It does seem somewhat similar to bug 
282573.  I'll try to glean something from that bug, to avoid using innerHTML, 
though we will still have to use that for IE support.  If you know of any good 
references that clearly describe substitutes for the (admittedly non-standard) 
innerHTML property, that would be helpful as well.  In the meantime, I'll look 
into a workaround.

Comment 3

[Ben Fowler]

(In reply to comment #2)
> If you know of any good  references that clearly describe substitutes for 
> the (admittedly non-standard) innerHTML property, that would be helpful

It depends what you mean by 'good'. In the past I have made trouble
for myself by pointing to references that were more elementary than
the querent wanted http://www.javascriptkit.com/javatutors/dynamiccontent4.shtml
or too advanced http://www.developer-x.com/content/innerhtml/ . Take your
pick.

See Bug 169429 "window.open fails, when the caller-code of a previous 
'open' call is overwritten"

I am fairly sure that DOM 0 (IE specific) support in Firefox is partial 
only, and the way forward is to use the W3C DOM; but I may be wrong.

I have found the relevant chapter in the O'Reilly Javascript book helpful,
but it may be slightly dated. 

Comment 4

[AJS]

Ben, both references were good.  Thanks for the pointers.  Those references 
enabled me to come up with a version that does not use innerHTML, and it turns 
out the bug is nothing to do with innerHTML anyway.  I'll explain.

New testcases:
http://www.geocities.com/asefkow/frames2/parent.htm
http://www.geocities.com/asefkow/frames3/parent.htm

They are the same except for in "frames2", the "if" statement is commented out 
in child.js, preventing the "src" attribute from being copied when its value 
is null.  The fact that this is needed is a bug, it seems, since the object it 
is being copied into is a "new" object, and the "src" attribute is already 
null.  Odd.

The second issue, which appears in both testcases, is that the upper-
right "loading logo" keeps spinning (and the progress bar continues) even 
after the scripts are finished.

So the "script not found" in the subject line is still accurate, though now 
there is more information pinpointing the actual code that appears to be 
failing (the copying of the scripts).  It's nothing to do with innerHTML as 
you can now see (all that code is gone in my testcase).

Comment 5

[PikeUK]

As I understand it, you're saying that if a src attribute doesn't exist on the
script element the corresponding src property should be null rather than the
empty string?

I think that make this Core->DOM:HTML, moving in that general direction.

Comment 6

[PikeUK]

Hmm, it seems all browsers I tried return an empty string for a non-existent
attribute but most will ignore src="" on a script and execute the contents
anyway, Firefox insteads executes the current page.

So looks like I moved this to completely the wrong place, but I have no idea
where it should be. :(

Comment 7

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 8

[AJS]

This bug still reproduces in the latest version of Firefox:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
Firefox/1.0.7

Comment 9

[Ben Fowler]

Are you sure that this is a bug?

Is there a standard with which we are not compliant?

See comment 4 .

Comment 10

[AJS]

Attachment: demonstrates the problem with "src"

Comment 11

[AJS]

Actually, I just tested this WITH the workaround, and from what I can tell, the
testcase is not working then either.  This is using Firefox 1.5 Beta 1.  Is this
a regression, then?  It seems like the "alert" script is never accessible to the
main document -- with or without the workaround, makes no difference.  In
Firefox 1.0.x, by contrast, the "alert" script is accessible WITH the workaround.

Comment 12

[Ben Fowler]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050822
Firefox/1.6a1

The reported behaviour is still in, that much is clear; and personally
I agree that it is surprising.

I am merely unsure that it is actually a bug - something not compliant with
a relevant standard - nor do I know to where this this bug should be 
assigned, see comment 5 and comment 6 .

Given the testcase, we probably only need a few pointers to get
on and fix it.

Comment 13

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

The specification is clear:

<http://www.whatwg.org/html/#running-a-script>:

> If the src attribute's value is the empty string or if it could not be
> resolved, then the user agent must queue a task to fire a simple event
> named error at the element, and abort these steps.

As those steps are aborted, the script is never executed.

However, we don't do that; we resolve "" to the current page and try to run it. Fixing that is bug 616248.

In both cases, setting src to the empty string has another meaning than not setting src at all, and in both cases, it will prevent execution. Hence, marking invalid.