620002 - Support SVG 2 event model (dispatch load rather than SVGLoad etc)

Status: NEW

(Core :: DOM: Events, enhancement, P3)

Description

[Cameron McCormack (:heycam)]

Attachment: Test

The spec says to dispatch a non-bubbling SVGLoad event: http://www.w3.org/TR/SVG/interact.html#LoadEvent

Comment 1

[Daniel Holbert [:dholbert]]

I'm pretty sure we only fire the 'load' event for <svg> elements right now.

This was discussed a bit in bug 552938 (and I think that's where we dropped it for other elements (?)).  See in particular bug 552938 Comment 27 and bug 552938 Comment 28.

Comment 2

[Cameron McCormack (:heycam)]

For some reason I thought that even HTML <img> elements get a load even dispatched, so that listening for it on SVG <image> wouldn't that crazy.  If our view is that load shouldn't dispatch anywhere except on the root element of a document, then that's fine.

Comment 3

[Robert Longson [:longsonr]]

html images do get an onload so svg images should get the SVG equivalent. I think this needs to be an exception to our svg only rule.

Comment 4

[Cameron McCormack (:heycam)]

OK, great.  As much as possible I'd like SVG's load event dispatching to be consistent with HTML's.

Comment 5

[Robert Longson [:longsonr]]

Attachment: hg changeset patch with reftest

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Could this break some existing content?
Should we perhaps dispatch both SVGLoad and load for now, and ask
SVG WG to drop SVGLoad eventually?

Comment 7

[Robert Longson [:longsonr]]

If you do <image onload="something()" .../> with an SVG image, nothing happens at the moment. The only other way to trigger something is addEventListener isn't it? So something doing addEventListener might change. Dispatching both seems reasonable to me.

We should ask the SVG WG to drop most of the SVG events. http://www.w3.org/TR/SVG/interact.html#SVGEvents 

SVGAbort and SVGError should go too and maybe others.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #7)
> If you do <image onload="something()" .../> with an SVG image, nothing happens
> at the moment.
Oh. I thought onload was supported in svg:img.

Comment 9

[Jonathan Watt [:jwatt]]

It is, just not by us.

I'd be in favor of just dispatching 'load' for now.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

We do have some special handling in
http://mxr.mozilla.org/mozilla-central/source/content/events/src/nsEventListenerManager.cpp#982

Comment 11

[Robert Longson [:longsonr]]

Attachment: dispatch both events and support onerror too

I think dispatching both events is the lowest risk option at this point. Converting to just onload risks us not doing the right think like having the correct bubbling and canceling properties.

Comment 12

[Jonathan Watt [:jwatt]]

I really don't want to dispatch SVGXxx events that we don't already dispatch. It will just make it harder to remove the SVGXxx event crap from the spec, and we'll have to live with it and dispatching two events forever. For the most part people will be using 'onload' and 'onerror' attributes and not checking the event name, so I think us using 'load' and 'error' is the better road.

Comment 13

[Robert Longson [:longsonr]]

We're already dispatching an SVGLoad event for the outer SVG element. If I remove the code that converts the SVGLoad event to call the onload handler then I'd have to dispatch an ordinary load event to the outer SVG. I'm not sure what the consequences of that would be and I'd be very hesitant therefore to make such a change.

Comment 14

[Robert Longson [:longsonr]]

The other alternative is to give up on this for 4.0

Comment 15

[Robert Longson [:longsonr]]

Or option c) dispatch load and SVGLoad but only dispatch error and not SVGError just remove the SVGError conversion.

Comment 16

[Cameron McCormack (:heycam)]

How about just dispatching load to <image>, making <image onload=""> trigger off that, and don't do anything to support addEventListener for SVGLoad?  That gets us part of the way to where we want to be and makes the test pass.  (None of the SVG 1.1 test suite tests currently use addEventListener to listen for any of the SVG* events.)

Comment 17

[Robert Longson [:longsonr]]

I don't think I can implement that without changing the outer SVG element SVGLoad to be load too.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think doing nothing here would be a better option than dispatching SVGLoad in more cases.

Let's go to the group ASAP and try to get agreement to drop the unnecessary SVG* events, then implement that post-FF4. How does that sound?

Comment 19

[Robert Longson [:longsonr]]

Comment on attachment 498620 [details] [diff] [review]
dispatch both events and support onerror too

Doing nothing is always an option :-)

Comment 20

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

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #18)
> I think doing nothing here would be a better option than dispatching SVGLoad
> in more cases.
> 
> Let's go to the group ASAP and try to get agreement to drop the unnecessary
> SVG* events, then implement that post-FF4. How does that sound?

Has this happened?

Comment 21

[Robert Longson [:longsonr]]

I raised it - http://lists.w3.org/Archives/Public/www-svg/2011Oct/0046.html. I don't think anything happened though.

Comment 22

[Cameron McCormack (:heycam)]

Once I get to reviewing/rewriting the Interaction chapter in SVG 2, I'll bring this up again.  I've added a note to the chapter to remind myself.

Comment 23

[Robert Longson [:longsonr]]

maybe this bug should be morphed into converting SVGxxx events to SVG 2/html events i.e.

OnSVGLoad becomes onload, same for onunload, onresize and onscroll.

onerror and onabort have been done in bug 500261 already as we never fired SVGError events.

Comment 24

[Cameron McCormack (:heycam)]

(In reply to Robert Longson from comment #23)
> maybe this bug should be morphed into converting SVGxxx events to SVG 2/html
> events i.e.
> 
> OnSVGLoad becomes onload, same for onunload, onresize and onscroll.

Sounds fine to me.