Closed
Bug 854213
Opened 12 years ago
Closed 2 years ago
In SVG event handlers, give access to the event via both 'evt' and 'event'
Categories
(Core :: SVG, enhancement)
Core
SVG
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: kari_pihkala, Unassigned)
References
Details
(Keywords: parity-chrome, parity-edge, parity-safari)
Attachments
(2 files, 1 obsolete file)
Testcase SVG document showing a rectangle with an onclick handler
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130307122853
Steps to reproduce:
I tried to access the event variable in the onlick event handler, but the variable is not set in SVG documents. Here's a test case, where the alert box should display the event variable:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 200 200">
<rect x="10" y="10" width="100" height="100" fill="blue" onclick="alert('Got event:'+event)"/>
</svg>
The event variable is not set in SVG embedded in HTML, either. It is set for the html <p> element, but not for the svg <text> element:
<html>
<body>
<p onclick="alert('HTML event:'+event)">HTML Click Me</p>
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 100 100" style="width: 100px; height: 100px;">
<text y="20" fill="blue" onclick="alert('SVG event:'+event)">SVG Click Me</text>
</svg>
</body>
</html>
Actual results:
The event variable is not set, the Web console says: "ReferenceError: event is not defined"
Expected results:
The event variable should have been set.
All other browsers set the event variable in the test cases and display the alert message. Tested with Chromium Version 25.0.1364.160 Ubuntu 12.04 (25.0.1364.160-0ubuntu0.12.04.1), Opera 12.14, IE10, Safari 5.
Attachment #728753 -
Attachment mime type: text/plain → text/html
|
||
Comment 2•12 years ago
|
||
Not standards compliant, but we should probably do this.
Severity: normal → enhancement
OS: Linux → All
Hardware: x86 → All
|
|
||
Comment 3•12 years ago
|
||
For SVG handlers, Chrome seems to detect whether a variable called 'event' is declared in the handler, and if not it creates such a variable and assigns it the same event object as 'evt'. I'm not sure how easy it is for us to be that smart about it.
Summary: The event variable is not set for onclick handlers in SVG documents → In SVG event handlers, give access to the event via both 'evt' and 'event'
|
|
||
Comment 4•12 years ago
|
||
Chrome's "smart" behavior gives funny results in the case that you try to examine 'event' before creating a variable of that name though. For example, if you have:
if (typeof event == "undefined") {
var event = undefined;
}
alert(event);
the alert alerts "undefined", but if you just have:
alert(event);
it alerts "[object MouseEvent]".
|
|
||
Comment 5•12 years ago
|
||
This is a bit hacky in that in nsJSEventListener::HandleEvent we'd only want to pass that optional argument in the case that we're dealing with an SVG handler. There aren't enough bits to add an eSVGHandler to nsEventHandler::HandlerType, so smaug suggested maybe creating an nsJSSVGEventListener subclass of nsJSEventListener and overriding HandleEvent.
This also doesn't bother trying to be smart about whether the handler defines an 'event' variable, but since the argument will simply be overridden if it does I'm not sure that's a problem.
Attachment #728774 -
Flags: feedback?(bzbarsky)
|
||
Comment 6•12 years ago
|
||
(In reply to Jonathan Watt [:jwatt] from comment #4)
> Chrome's "smart" behavior gives funny results in the case that you try to
> examine 'event' before creating a variable of that name though. For example,
> if you have:
>
> if (typeof event == "undefined") {
> var event = undefined;
> }
> alert(event);
Because of var declaration hoisting, this is actually equivalent to:
var event;
if (typeof event == "undefined") {
event = undefined;
}
alert(event);
So the var declaration will shadow the "event" property on the scope chain and initialize it to undefined.
|
|
||
Comment 7•12 years ago
|
||
> For SVG handlers, Chrome seems to detect whether a variable called 'event' is declared in
> the handler, and if not it creates such a variable and assigns it the same event object
> as 'evt'.
Nothing of the sort, sadly. WebKit just implements IE's window.event thing. So when you do a bareword "event" in the click handler you get window.event.
You can test this by putting "document.event = 5;" somewhere in a script before the event handler runs and observing that the alert in the attached testcase then shows "5".
What is the spec plan for this, exactly? If there is no existing proposal, then whatever we implement we should just propose as the spec...
|
|
||
Comment 8•12 years ago
|
||
Comment on attachment 728774 [details] [diff] [review]
hacky patch to add 'event' argument
So this patch always passes two arguments to the event handler, right? That's definitely a web-detectable standards-violation for non-SVG elements, which doesn't make me all that happy. Why are we doing that?
|
|
||
Comment 9•12 years ago
|
||
Fundamentally, this bug report is a request for us to implement window.event. Which we should probably get specified, then implement based on that spec....
|
|
||
Updated•12 years ago
|
Flags: needinfo?(bugs)
Flags: needinfo?(annevk)
|
||
Comment 10•12 years ago
|
||
Yeah, normal EventHandlers shouldn't get params, but in case of SVG that might be ok.
But indeed if window.event was spec'ed, we could implement that.
Flags: needinfo?(bugs)
|
||
Comment 11•12 years ago
|
||
Flags: needinfo?(annevk)
|
|
||
Comment 12•12 years ago
|
||
Comment on attachment 728774 [details] [diff] [review]
hacky patch to add 'event' argument
(In reply to Boris Zbarsky (:bz) from comment #8)
> So this patch always passes two arguments to the event handler, right?
Right.
> That's definitely a web-detectable standards-violation for non-SVG elements,
> which doesn't make me all that happy. Why are we doing that?
This patch was intended to be considered along with its comment (comment 5) where I mentioned we'd want to have a nsJSSVGEventListener, or figure out something with the bit flags...or something. I didn't intend to propose it as-is, but rather was requesting feedback about which direction to take before coding up any specific direction.
Anyway, it seems this isn't the route we want to take at all.
Attachment #728774 -
Attachment is obsolete: true
Attachment #728774 -
Flags: feedback?(bzbarsky)
|
|
||
Comment 13•12 years ago
|
||
Ah, ok. So in terms of which route we want to take... that's unclear. Maybe passing two arguments to SVG handlers is in fact a good idea.
|
|
||
Comment 14•12 years ago
|
||
_If_ we implement window.event, there would be no reason to do that though, right?
|
|
||
Comment 15•12 years ago
|
||
Or rather, we probably wouldn't.
|
|
||
Comment 16•12 years ago
|
||
Yes, if we implement window.event there wouldn't be much reason.
|
|
||
Updated•7 years ago
|
|
||
Updated•2 years ago
|
Severity: normal → S3
|
||
Comment 18•2 years ago
|
||
Should this be closed now that bug 218415 is fixed?
|
||
Updated•2 years ago
|
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•