currentScale / currentTranslate have no effect on inline SVG

NEW
Assigned to

Status

()

Core
SVG
11 years ago
9 years ago

People

(Reporter: Olivier, Assigned: Hardeep)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
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.
(Reporter)

Comment 1

11 years ago
Created attachment 250447 [details]
currentScale working on a svg document

currentScale working on a svg document
(Reporter)

Comment 2

11 years ago
Created attachment 250448 [details]
Svg fragment in a xul document. Doesn't work...

Updated

10 years ago
Summary: currentScale / Translate have no effect on embedded svg → currentScale / currentTranslate have no effect on inline SVG

Updated

10 years ago
Duplicate of this bug: 371490

Comment 4

9 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

9 years ago
Duplicate of this bug: 487822

Updated

9 years ago
Assignee: general → shokerhardeep
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
QA Contact: ian → general
Hardware: x86 → All

Updated

9 years ago
Depends on: 474230

Comment 6

9 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

9 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

9 years ago
If we don't want to expose initSVGZoomEvent() to scripts,
nsIDOMNSSVGZoomEvent could be a non-scriptable interface.
(Assignee)

Comment 9

9 years ago
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.
You need to log in before you can comment on or make changes to this bug.