Open Bug 365901 Opened 18 years ago Updated 2 years ago

currentScale / currentTranslate have no effect on inline SVG

Categories

(Core :: SVG, defect)

defect

Tracking

()

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.
currentScale working on a svg document
Summary: currentScale / Translate have no effect on embedded svg → currentScale / currentTranslate have no effect on inline SVG
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].
Assignee: general → shokerhardeep
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
QA Contact: ian → general
Hardware: x86 → All
Depends on: 474230
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.
(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.
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
(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.

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)
Flags: needinfo?(jwatt)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: