Closed Bug 83332 Opened 24 years ago Closed 24 years ago

setting image.src in window onload handler causes NS_ERROR_FAILURE

Categories

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

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla0.9.2

People

(Reporter: jsp, Assigned: jst)

References

Details

(Keywords: regression, Whiteboard: [HAVE FIX])

Attachments

(3 files)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9+) Gecko/20010529 BuildID: 2001052904 You can set an image element's src attribute in a window onload handler with element.setAttribute("src", "whatever"), but not with element.src="whatever". Reproducible: Always Steps to Reproduce: 1. Open the JavaScript console and clear any messages. 2. Load the attachment. Actual Results: The following message appears in the JavaScript console: Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMHTMLImageElement.src]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://yoursite/thefile.htm :: OnWndLoad :: line 12" data: no] Source File: http://yoursite/thefile.htm Line: 12 The line referred to uses element.src="whatever" syntax to specify an image element's src attribute. The preceding line uses element.setAttribute() to set the same attribute, and produces no warnings or errors. Expected Results: No errors should have occurred, and an alert box indicating that the handler function ran to completion should have been displayed.
Attached file Test case
FWIW, this is a regression since M0.9.
i'm seeing this too, on mac. i am not allowed to change the status to new and platform/os to all/all, someone please do this. i think this is in one way or another related to bug 81115 and bug 82092, which show much the same kind of problem, ie. eventhandling is slightly **** up since 0.9.
OS: All, status: NEW, keyw: regression, mozilla1.0. Does this only happen from events, or also from simple instructions?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
I've only seen this problem in the window onload handler. The same code works fine in a body element onload handler, and in global code (that is, code outside any function context, which I assume is what is meant by "simple instructions").
Further exploration reveals that the problem seems to occur in any event handler established using the DOM2 addEventListener() method. Event handlers established with the HTML on[event] attributes don't have this problem. I'll attach an updated test case that includes two paragraphs that share a click event handler. In one case, it's established with the HTML onclick attribute, the other, with addEventListener(). The handler works in the first case but not the second.
Attached file Updated test case
Jband, David, here's the stack for the failing img.src='...'; nsHTMLImageElement::SetSrc() line 1060 + 29 bytes XPTC_InvokeByIndex() line 139 XPCWrappedNative::CallMethod() line 1835 + 42 bytes XPCWrappedNative::SetAttribute() line 1730 + 14 bytes XPC_WN_GetterSetter() line 1265 + 9 bytes js_Invoke() line 807 + 23 bytes js_InternalInvoke() line 896 + 20 bytes js_SetProperty() line 2554 + 47 bytes js_Interpret() line 2546 + 1939 bytes js_Invoke() line 824 + 13 bytes nsXPCWrappedJSClass::CallMethod() line 968 + 21 bytes nsXPCWrappedJS::CallMethod() line 427 PrepareAndDispatch() line 100 + 31 bytes SharedStub() line 124 nsEventListenerManager::HandleEventSubType() line 1119 + 20 bytes nsEventListenerManager::HandleEvent() line 1790 + 36 bytes GlobalWindowImpl::HandleDOMEvent() line 609 We're trying to set the source of an image to a relative URL and since this event handler is an nsIDOMEventListener we end up calling throught this "function" interface into XPConnect and the event handler ends up executing on the safe context (i.e. in the hidden window in mozilla). This should be fixed by making the nsEventListenerManager push the right context onto the context stack before calling the event handler, right?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.2
Attached patch Proposed fixSplinter Review
Whiteboard: [HAVE FIX]
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala
Adding patch, review keywords. Would be nice to have this reviewed.
Keywords: patch, review
Yeah, this seems like the right thing to do. Since this is a fairly recent regression I'm hoping that no one is depending on the broken behavior. r=joki
Keywords: mozilla0.9.2
sr=hyatt
a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)
Blocks: 83989
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 86307 has been marked as a duplicate of this bug. ***
*** Bug 86381 has been marked as a duplicate of this bug. ***
WFM with 2001062009 on Windows 2000. Thanks!
ah, this finally fixes bug 82092, just as i assumed. thanks a lot!
*** Bug 82092 has been marked as a duplicate of this bug. ***
verifying fixed on build 2001-06-21-04-trunk
Status: RESOLVED → VERIFIED
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: