84512 - document.write() of image tag throws script error

Status: RESOLVED FIXED

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

Description

[bht237]

BuildID:    2001053104

Detailed description will follow. Need this to have a reference for Quality 
Feedback Agent

Comment 1

[bht237]

Attaching testcase. The testcase itself does NOT crash - the crash occurs in
another page that I haven't managed to reduce to a testcase (time constraints!).

However, I guess that the complex page would NOT crash if the attached testcase
worked without the error.

The error is:
"[xpconnect wrapped Event]"
The error is displayed in an alert box from within function errorHandler(t,u,n).

This needs to be fixed because it corrupts error handlers AND crashes Mozilla!

Comment 2

[bht237]

Attachment: HTML reproduces error

Comment 3

[Phil Schwartau]

Confirming with 20010607xx nightly binaries on WinNT, Linux, Mac.
OS : Win95 --> All.

Comment 4

[John Bandhauer]

It is hard to debug a crash without know what's crashing or seeing it crash.

I'd bet you are looking at a DOM event problem rather than an xpconnect problem. 
It overloads the event scheme in order to do onerror handling. Dis you see some 
crash that led you to think it was crashing in xpconnect? Or was it just the 
"xpconnect wrapped Event" in the alert that led you to that? If the former then 
we'd need to reproduce the crash and see where and why. If the latter then 
xpconnect is not really implicated at all and this bug should be reassigned to 
[e-mail] who owns DOM event bugs for the speediest resolution.

Comment 5

[David Bradley]

John, was just going to cc you on this. I'm getting the alerts, but no crash. 
I'm going to try and pin down a stack trace at the alert box and see if that 
leads to anything

Comment 6

[David Bradley]

Attachment: Stack trace to the xpconnect alert box

Comment 7

[David Bradley]

Some of the other dynamics are that there are popup's firing due to timers while 
the xpconnect alert message is displayed. I'll attach a stack trace showing 
this. I've  slightly annotated the stack to show each alert text, look for the 
brackets.

Comment 8

[David Bradley]

Attachment: This stack shows two alerts along with the xpconnect one

Comment 9

[Johnny Stenback (:jst)]

This is kindof a known problem, alert's opened from DOM timers can pop up even
if there's a modal dialog currently open. Unless I missed something about
problems in XPConnect described in this bug this bug belongs to the DOM Level 0
component (i.e. to me)...

Comment 10

[John Bandhauer]

I agree that there is no evidence that an xpconnect bug exists here. I'm just 
going to be pushy and reassign it to jst as he suggested. The issue that I was 
unclear about is what in the testcase code is causing the onerror to fire. I was 
concerned that some other events where getting routed to the onerror handler 
path. That would be bad. I know we're already generally overloading the event 
scheme to do onerror. And that is bad enough. There is also a bug on joki's list 
somewhere about the fact that the other two spec'd params are not being properly 
passed to onerror handlers. I *really* would like us to find the time to fix 
this stuff as we settle into the new XPCDOM world.

Comment 11

[bht237]

The onerror bug that John refers to is probably bug 52120.

Although the initial description of THIS bug includes "crash", I suggest to
treat the crash (and the multiple dialogs) as secondary issues.
Primary issue IMHO is that onerror is fired, which can cause havoc in an
application that uses onerror for anything useful.

However, if the crash is also important to you then please get back to me and I
will try to get time to write a testcase.
I only got the crash because I used alerts to show the onerror events.

Comment 12

[Scott Turner]

I can't tell from the comments whether this is related, but the following page:

  http://www.kurzeilai.net/articles/art0134.html

produces an (apparently) endless stream of "xpconnect wrapped event" alerts.

Please feel free to open this as a separate bug if proper.

Comment 13

[John Bandhauer]

jst: It would be nice if those event object had toString methods so they 
wouldn'd print as "xpconnect wrapped event". Even always returning just 'Event' 
would be less ugly.

Comment 14

[David Bradley]

I'm unable to access kurzeilai.net, it's not getting resolved by my DNS server. 
Are you sure you got the URL correct?

Comment 15

[Johnny Stenback (:jst)]

jband: I don't see how adding a toString() method to Event's would solve any
problems, Event objects are just like any other DOM objects, if we add a
toString() method on Event objects we'd haveto add toString() methods to all our
DOM objects and that I *really* don't wanto do.

Comment 16

[bht237]

I can't see the benefit of toString() even in the scope of this bug but it is
likely that I miss something.
If I do

<html>
<script>
function init(){
    alert("Caller = "+init.caller);
}
</script>
</head>
<body onLoad="init()">
</body>
</html>

then I get "event", the same as in Netscape 4 so that's perfect.

To me it would be quite interesting to have error text, URL, line number, and
column number (yes, column number) in a window.onerror handler.

Anyway, thanks for your great work, Mozilla looks better every day :)

Comment 17

[Scott Turner]

Sorry, my bad.  I dropped a "w" from the URL:

  http://www.kurzweilai.net/articles/art0134.html

Hope that helps.

Comment 18

[David Bradley]

Yes, that URL works, Scott. And it appears similar, if not the same. It's 
getting an alert box popped because an image failed to load.

Comment 19

[Johnny Stenback (:jst)]

Targetting for mozilla1.1

Comment 20

[bht237]

Testcase fails in Netscape Preview 6.1 (works fine in Netscape 6).

Are you sure that this should not be fixed earlier than mozilla1.1 ?
It's a very nasty bug that fouls up any error handler.
We would have to write separate Netscape 6.1 error handling code just for this bug.
Considering that this browser should make web page authoring easier, this is not
good for Netscape/Mozilla.

Comment 21

[bht237]

Attachment: Basic minimal testcase

Comment 22

[bht237]

This garbage is unacceptable. Changed description. Added keywords.

Suppose a serious e-commerce site depends on JavaScript for its client-side
logic such as form validation.

Then it is fair to assume that this site does not simply ignore script errors.
So "window.onerror=null;" etc. is not an option.

In this case one must conclude that the Mozilla/Netscape browser is not fit for
e-commerce.

Why?

One cannot even work around this bug by filtering out the

"[xpconnect wrapped Event]"

"message" because the error handler gets passed this as an _object_ not having a
toString() method (instead of an error message string as usual).
Would someone please give this more attention and fix it.

Comment 23

[bht237]

We are getting stuck with this because of bug 52120.
Both this and bug 52120 combined mean that error handling is completely corrupted.

The error thrown by this bug cannot be distinguished from a genuine error
because error message text is not yet implemented.

It means that applications fail without genuine errors if error handling is
enabled . Quite an unusual behavior for any software environment.

I thought that the Mozilla browser is targeting ecommerce applications but how
can that be achieved if such a basic prerequisite is broken?

Am I overlooking anything?

Comment 24

[Fabian Guisset]

Is an acceptable workaround the use of document.createElement("image") and
node.appendChild(imageElement)?

Comment 25

[bht237]

Thanks for the workaround suggestion. It wouldn't work for us because of
cross-browser compatibility issues.
I hope that this bug is going to be fixed soon indirectly, as general js error
handling appears to be worked on at the moment -> bug 52120 ,-> bug 79133
Added dependencies so this can be closed more easily.

Comment 26

[basic]

build 2001120603 win32 seems to wfm

I'm guessing this is because bug 79133 is fixed. Is more investigation needed?

Comment 27

[bht237]

I don't think that ore investigation is needed. Should be closed I think.

Comment 28

[Fabian Guisset]

Marking FIXED per bht and _basic's comments then, thanks :-)