Open
Bug 365901
Opened 18 years ago
Updated 2 years ago
currentScale / currentTranslate have no effect on inline SVG
Categories
(Core :: SVG, defect)
Core
SVG
Tracking
()
NEW
People
(Reporter: viapanda, Unassigned)
References
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1.1) Gecko/20061205 Iceweasel/2.0.0.1 (Debian-2.0.0.1+dfsg-1) Build Identifier: Mozilla XULRunner 1.9a1 Setting currentScale apparently only has effect on svg documents. If the svg fragment is embedded in another document (xhtml / xul), setting currentScale doesn't have any effect. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Updated•17 years ago
|
Summary: currentScale / Translate have no effect on embedded svg → currentScale / currentTranslate have no effect on inline SVG
Comment 4•16 years ago
|
||
Still not fixed as of this date. This problem also exists for the currentTranslate Attempting work around using transform="matrix(...);" as hinted by http://www.w3.org/TR/2004/WD-SVG12-20040318/svgudom.html using 2x3 matrix [a b c d e f] = [currentScale 0 0 currentScale currentTranslate.x currentTranslate.y].
Updated•15 years ago
|
Assignee: general → shokerhardeep
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
QA Contact: ian → general
Hardware: x86 → All
Comment 6•15 years ago
|
||
Fixing this requires that also SVGZoom event implementation is changed a bit. Currently nsDOMSVGZoomEvent initializes its member variables in constructor using document's root element, but IMO it would be better to have initSVGZoomEvent method. So for that it might be good to add a new interface which nsDOMSVGZoomEvent implements. interface nsIDOMNSSVGZoomEvent : nsIDOMSVGZoomEvent { void initSVGZoomEvent(in DOMString typeArg, in boolean canBubbleArg, in boolean cancelableArg, in nsIDOMAbstractView viewArg, in long detailArg, in nsIDOMSVGRect zoomRectScreen, in float previousScale, in nsIDOMSVGPoint previousTranslate, in float newScale, in nsIDOMSVGPoint newTranslate); } Then SVGZoom event would be initialized using that method before dispatching. And dispatching shouldn't depend on whether <svg> is the root element. Though, I'm not quite sure why there is this http://mxr.mozilla.org/mozilla-central/source/content/svg/content/src/nsDOMSVGZoomEvent.cpp?mark=97-99#90 Btw, SVG1.1 definition for SVGZoom is pretty terrible. What does this actually mean: "The zoom event handler occurs before the zoom event is processed."? I guess it should be more like: zoom is done before the event is dispatched. And the context info for the event mentions clientX/Y, screenX/Y etc which are properties of MouseEvent, not UIEvent. Clearly something to fix in SVG 1.1 errata. I'll write a mail to SVG WG.
Comment 7•15 years ago
|
||
(In reply to comment #6) > Clearly something to fix in > SVG 1.1 errata. I'll write a mail to SVG WG. Ah, jwatt reported this to wg already long ago.
Comment 8•15 years ago
|
||
If we don't want to expose initSVGZoomEvent() to scripts, nsIDOMNSSVGZoomEvent could be a non-scriptable interface.
My only concern is that in order for this zoom to work it's going to require a target. If the initSVGZoomEvent is not scriptable we have no way to specify a target. Currently svg zoom does not need a target node because it acts upon the root node however if we are going to change this then we need it to be able to be zoomable on any node. In order for that to happen we cannot have initSVGZoomEvent because we could not give it a target through create event. Having said that we would have to give it a target through dispatch and in order to capture that we need to have the listener. That is what my comments are on the svg zoom situation. Hardeep
Comment 10•15 years ago
|
||
(In reply to comment #9) > My only concern is that in order for this zoom to work it's going to require a > target. You know the target when you dispatch the event to the <svg> element. > If the initSVGZoomEvent is not scriptable we have no way to specify a > target. Being scriptable or not has nothing to do with target. > Currently svg zoom does not need a target node because it acts upon the > root node No. The event is currently dispatched to <svg> element. However, there is currently the limitation, that it is dispatched only when <svg> is the root element. That limitation is the thing you should remove. > however if we are going to change this then we need it to be able to > be zoomable on any node. In order for that to happen we cannot have > initSVGZoomEvent because we could not give it a target through create event. .initXXXEvent never sets the target. It happens when dispatchEvent is called. And you know what the target is, because you call dispatchEvent. > Having said that we would have to give it a target through dispatch and in > order to capture that we need to have the listener. You don't need to capture SVGZoom. It is web pages or similar which adds listeners for the event. SVGZoom is dispatched after <svg> element is actually zoomed. Btw, SVG 1.1 has this: "The zoom event occurs when the user initiates an action which causes the current view of the SVG document fragment to be rescaled." So the current, dispatch-svgzoom-always isn't quite right.
Comment 11•2 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months.
:jwatt, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee: shokerhardeep → nobody
Flags: needinfo?(jwatt)
Updated•2 years ago
|
Flags: needinfo?(jwatt)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•