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)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
mozilla0.9.2
People
(Reporter: jsp, Assigned: jst)
References
Details
(Keywords: regression, Whiteboard: [HAVE FIX])
Attachments
(3 files)
1.95 KB,
text/html
|
Details | |
3.39 KB,
text/html
|
Details | |
1.63 KB,
patch
|
Details | Diff | Splinter Review |
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.
Comment 4•24 years ago
|
||
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
Keywords: mozilla1.0,
regression
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.
Assignee | ||
Comment 8•24 years ago
|
||
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
Assignee | ||
Comment 9•24 years ago
|
||
Assignee | ||
Updated•24 years ago
|
Whiteboard: [HAVE FIX]
Comment 11•24 years ago
|
||
Adding patch, review keywords. Would be nice to have this reviewed.
Comment 12•24 years ago
|
||
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
Assignee | ||
Updated•24 years ago
|
Keywords: mozilla0.9.2
Comment 13•24 years ago
|
||
sr=hyatt
Comment 14•24 years ago
|
||
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
Assignee | ||
Comment 15•24 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
![]() |
||
Comment 16•24 years ago
|
||
*** Bug 86307 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 17•24 years ago
|
||
*** Bug 86381 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 18•24 years ago
|
||
WFM with 2001062009 on Windows 2000. Thanks!
Comment 19•24 years ago
|
||
ah, this finally fixes bug 82092, just as i assumed. thanks a lot!
Comment 20•24 years ago
|
||
*** Bug 82092 has been marked as a duplicate of this bug. ***
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.
Description
•