Last Comment Bug 365901 - currentScale / currentTranslate have no effect on inline SVG
: currentScale / currentTranslate have no effect on inline SVG
Status: NEW
:
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
: -- normal with 2 votes (vote)
: ---
Assigned To: Hardeep
:
Mentors:
: 371490 487822 (view as bug list)
Depends on: 474230
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-04 02:55 PST by Olivier
Modified: 2009-04-13 02:54 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
currentScale working on a svg document (286 bytes, image/svg+xml)
2007-01-04 02:57 PST, Olivier
no flags Details
Svg fragment in a xul document. Doesn't work... (437 bytes, application/vnd.mozilla.xul+xml)
2007-01-04 03:00 PST, Olivier
no flags Details

Description Olivier 2007-01-04 02:55:10 PST
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.
Comment 1 Olivier 2007-01-04 02:57:36 PST
Created attachment 250447 [details]
currentScale working on a svg document

currentScale working on a svg document
Comment 2 Olivier 2007-01-04 03:00:15 PST
Created attachment 250448 [details]
Svg fragment in a xul document. Doesn't work...
Comment 3 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2007-12-03 16:21:02 PST
*** Bug 371490 has been marked as a duplicate of this bug. ***
Comment 4 Fredrick Paul Eisele 2008-06-01 17:03:09 PDT
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].
Comment 5 Jonathan Watt [:jwatt] (back in October - email directly if necessary) 2009-04-11 03:39:36 PDT
*** Bug 487822 has been marked as a duplicate of this bug. ***
Comment 6 Olli Pettay [:smaug] 2009-04-11 10:56:23 PDT
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 Olli Pettay [:smaug] 2009-04-11 11:26:19 PDT
(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 Olli Pettay [:smaug] 2009-04-11 11:29:48 PDT
If we don't want to expose initSVGZoomEvent() to scripts,
nsIDOMNSSVGZoomEvent could be a non-scriptable interface.
Comment 9 Hardeep 2009-04-12 21:16:39 PDT
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 Olli Pettay [:smaug] 2009-04-13 02:54:24 PDT
(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.

Note You need to log in before you can comment on or make changes to this bug.