Closed
Bug 500261
Opened 16 years ago
Closed 11 years ago
svg image onerror fails to fire on any error
Categories
(Core :: SVG, defect)
Tracking
()
RESOLVED
FIXED
mozilla30
People
(Reporter: wayfarer3134, Assigned: longsonr)
References
(Depends on 1 open bug)
Details
Attachments
(4 files, 2 obsolete files)
202 bytes,
application/xhtml+xml
|
Details | |
537 bytes,
application/xhtml+xml
|
Details | |
1.79 KB,
patch
|
Details | Diff | Splinter Review | |
6.61 KB,
patch
|
heycam
:
review+
smaug
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11
If there is an onerror method attached to either an svg:image or xhtml:img tag, they will fail to fire if either the server is missing or a 404 is returned. I didn't have any easy way to test other error codes, but I expect this is generally true. Note that this is a super-set of the bug reported in 299138, where that issue is only about 404 errors returning an image. In this case, any 404 returned, even html, or a 0 (server gone) is silently ignored, and no image is displayed, nor is the callback called.
Reproducible: Always
Steps to Reproduce:
Try loading the following file as XHTML. It should give you 2 error alerts, but instead gives you none.
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xlink="http://www.w3.org/1999/xlink" >
<body>
<p>This is an HTML paragraph</p>
<div style="width:300px; height:100px; background:cyan; position: relative;">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="300" height="100"
viewBox="0 0 100 100" preserveAspectRatio="xMidYMid slice"
style="width:300px; height:100px; ">
<image width="300" height="100" xlink:href="http://localhost/noServer.gif" preserveAspectRatio="none" onerror="alert(1)" />
</svg>
</div>
Done.
<img src="http://localhost/noServer.gif" onerror="alert(2)" />
</body>
</html>
Actual Results:
onerror is ignored every time. I was unable to find any case where onerror was successfully called.
Expected Results:
alert 1 and 2 are both shown (unless you happen to have the gif I reference which seems unlikely)
Reporter | ||
Updated•16 years ago
|
Summary: Both regular and svg img and image tags onerror fail to fire on any error → svg image onerror fails to fire on any error
Reporter | ||
Comment 1•16 years ago
|
||
I had noscript for files on - the svg image onerror still fails, but the second alert(2) displays just fine.
Also, for the svg reference about having onerror, I'm using:
http://www.w3.org/TR/SVG11/interact.html#SVGEvents
Assignee | ||
Updated•16 years ago
|
Component: General → SVG
Product: Firefox → Core
QA Contact: general → general
Assignee | ||
Comment 2•16 years ago
|
||
Can you add the testcase as an attachment please? Ideally as two separate attachments (one for html only and another containing only as the svg example)
Assignee | ||
Comment 3•16 years ago
|
||
Attachment #385018 -
Flags: review?(jwatt)
Assignee | ||
Updated•16 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Updated•16 years ago
|
Assignee: nobody → longsonr
Reporter | ||
Comment 4•16 years ago
|
||
This is the html test case that already passes.
Reporter | ||
Comment 5•16 years ago
|
||
Comment 6•15 years ago
|
||
Comment on attachment 385018 [details] [diff] [review]
patch
This seems wrong to me. The spec says that the 'onerror' attribute on SVG content triggers for the 'SVGError' event, not the 'error' event. Hence what nsSVGElement::GetEventNameForAttr is for.
Comment 7•15 years ago
|
||
Any thoughts on that Robert?
Assignee | ||
Comment 8•15 years ago
|
||
I think you're right. Unfortunately I'm not sure what to do about it :-( You know the events code better than me I think.
Assignee | ||
Updated•15 years ago
|
Attachment #385018 -
Flags: review?(jwatt)
Assignee | ||
Comment 9•15 years ago
|
||
Attachment #385018 -
Attachment is obsolete: true
Attachment #404500 -
Flags: review?(jwatt)
Assignee | ||
Updated•15 years ago
|
Attachment #404500 -
Flags: review?(Olli.Pettay)
Comment 10•15 years ago
|
||
Comment on attachment 404500 [details] [diff] [review]
better patch
Could you add some simple testcase for this.
I'm not sure we actually fire abort, but dispatching abort manually should be handle by onabort listener.
Assignee | ||
Comment 11•15 years ago
|
||
Assignee | ||
Comment 12•15 years ago
|
||
(In reply to comment #10)
> (From update of attachment 404500 [details] [diff] [review])
> Could you add some simple testcase for this.
Done.
>
> I'm not sure we actually fire abort, but dispatching abort manually should be
> handle by onabort listener.
I don't fire abort internally either.
Assignee | ||
Updated•15 years ago
|
Attachment #404500 -
Flags: review?(Olli.Pettay)
Assignee | ||
Updated•15 years ago
|
Assignee: longsonr → nobody
Assignee | ||
Comment 13•14 years ago
|
||
Comment on attachment 404500 [details] [diff] [review]
better patch
bitrotted now
Attachment #404500 -
Attachment is obsolete: true
Attachment #404500 -
Flags: review?(jwatt)
Assignee | ||
Comment 14•11 years ago
|
||
Seems that SVG 2 will use the standard CSS error and abort events per http://www.w3.org/TR/SVG2/interact.html#SVGEvents
We never fired the SVG 1.1 SVGError event so we've no backwards compatibility worries.
Attachment #8375406 -
Flags: review?(cam)
Comment 15•11 years ago
|
||
Comment on attachment 8375406 [details] [diff] [review]
The SVG 2 way
Review of attachment 8375406 [details] [diff] [review]:
-----------------------------------------------------------------
r=me for the SVG bits but can you get smaug or masayuki to review the dom/events/ bits?
Attachment #8375406 -
Flags: review?(cam) → review+
Assignee | ||
Updated•11 years ago
|
Attachment #8375406 -
Flags: superreview?(bugs)
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → longsonr
Updated•11 years ago
|
Attachment #8375406 -
Flags: superreview?(bugs) → superreview+
Assignee | ||
Comment 16•11 years ago
|
||
Assignee | ||
Comment 17•11 years ago
|
||
Flags: in-testsuite+
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in
before you can comment on or make changes to this bug.
Description
•