461751 - SVG zoomAndPan="disable" prevents programmatic zoom

Status: VERIFIED FIXED

(Core :: SVG, defect)

Description

[Duncan Loveday]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081026 Minefield/3.1b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081026 Minefield/3.1b2pre

Adding zoomAndPan="disable" prevents the zoom level of an SVG being set programmatically, e.g. by changing currentScale

Reproducible: Always

Steps to Reproduce:
1. Open the attached html test case
2. Click both pairs of zoom in and zoom out buttons
3.
Actual Results:  
The first pair of buttons have no effect.

Expected Results:  
The first pair of buttons should zoom the first SVG in the same way as the second pair of buttons zoom the second SVG.

The only difference between the two SVGs is that the first has zoomAndPan="disable". According to the SVG specification this should disable any UI zoom controls (though there are none in Firefox) but not prevent programmatic zoom.

Comment 1

[Duncan Loveday]

Attachment: SVG with zoomAndPan="disable"

Comment 2

[Duncan Loveday]

Attachment: SVG without zoomAndPan="disable"

Comment 3

[Duncan Loveday]

Attachment: HTML test case

Comment 4

[Duncan Loveday]

For comparison, try this in Opera. Both sets of buttons work but the first SVG has the context menu zoom options greyed out.

Comment 5

[Robert Longson [:longsonr]]

This is what the SVG specification says about currentScale

float currentScale
    This attribute indicates the current scale factor relative to the initial view to take into account user magnification and panning operations, as described under Magnification and panning. DOM attributes currentScale and currentTranslate are equivalent to the 2x3 matrix [a b c d e f] = [currentScale 0 0 currentScale currentTranslate.x currentTranslate.y]. If "magnification" is enabled (i.e., zoomAndPan="magnify"), then the effect is as if an extra transformation were placed at the outermost level on the SVG document fragment (i.e., outside the outermost 'svg' element). 

Which is what we do. i.e. if you have zoomAndPan="magnify" we use the currentScale/translate matrix, otherwise we don't.

ZoomAndPan is not mentioned in the spec as being something that is connected with the UI in any way as far as I can tell.

If you want it to work the Opera way i.e be something that is always in effect but acts to disable UI panning/zooming controls then you need to raise it on http://lists.w3.org/Archives/Public/www-svg/

Can you also confirm that the Adobe plug in does what Opera does?

Comment 6

[Duncan Loveday]

Attachment: Test case that works in IE, Fx, Opera.

Behaviour in IE/ASV is much the same as Opera - with zoomAndPan="disable", context menu items for zoom in and zoom out are greyed out and the ASV Alt-click and drag operations are disabled whilst programmatic zooming continues to work. Strangely, "Original View" is still available after programmatic zoom even when zoomAndPan="disable" is used.

Comment 7

[Duncan Loveday]

(In reply to comment #5)
> ZoomAndPan is not mentioned in the spec as being something that is connected
> with the UI in any way as far as I can tell.

If that is the case then this should be marked as invalid shouldn't it ? I only put this in because of our earlier discussion when I got the impression from you and Jonathan that the zoomAndPan attribute was all about the UI.

Comment 8

[Robert Longson [:longsonr]]

We think that the current definition does not seem too useful and neither Adobe nor Opera have followed it so perhaps www-svg can just change it. At that point this bug would not be invalid. If you email  w3c we can determine what to do with this bug based on their response.

Comment 9

[Robin Berjon]

I think that the wording of the zoomAndPan section in the latest spec (http://www.w3.org/TR/SVGMobile12/interact.html#ZoomAndPanAttribute) is *somewhat* clear that it's intended to place restrictions on the UI, not the content (there are similar things for Flash). It could be clarified though.

I've written quite a fair bit of zoomAndPan=disable content in my time that relied on this behaviour, so I'd expect things to break with Mozilla's current approach.

Comment 10

[Duncan Loveday]

> ... so I'd expect things to break with Mozilla's current
> approach.

My app was indeed broken on Mozilla when I tried to use zoomAndPan="disable". Though at one point I was compensating for this by doing something strange with the viewbox.

Not wanting to put a spanner in the works but I tried my test case with the Webkit browsers (Safari and Chrome) and although I couldn't get zoom to work properly with zoomAndPan defaulted they do seem to disable it when zoomAndPan="disabled" is set.

I guess the thing to do is follow the *intent* of the spec, clarifying it as needed. It seems a bad idea to block programmatic zoom since (i) the web developer can do that themselves by disabling or their own controls (or not providing any) and (ii) it would make it impossible for the web developer to disable the native UI controls and provide their own alternative ones since his/her choices would be to either enable or disable both.

Comment 11

[Robin Berjon]

What Duncan said. Having in the past worked on the spec I can testify that the intent is clearly to disable the UI (which is why the blurb on zoomAndPan talks of UI, but not of the rest, even though it could do with circumlocuting less around it).

I'd like to strengthen the strong case put forward in Duncan's last paragraph by saying that having an attribute disable some scripting behaviour would be quite silly — if you don't want your script to zoom or , don't have it zoom or pan! You can work around this bug in Mozilla by changing the attribute, zooming, and then changing it back but let's face it: that's just plain silly. The only way this attribute makes sense is for the UI, and it should be implemented that way.

Comment 12

[Robert Longson [:longsonr]]

(In reply to comment #11)
> I'd like to strengthen the strong case put forward in Duncan's last paragraph
> by saying that having an attribute disable some scripting behaviour would be
> quite silly — if you don't want your script to zoom or , don't have it zoom or
> pan! You can work around this bug in Mozilla by changing the attribute,
> zooming, and then changing it back but let's face it: that's just plain silly.
> The only way this attribute makes sense is for the UI, and it should be
> implemented that way.

That's not true, you cannot work around this issue in Mozilla by doing that. zoomAndPan="disable" will stop the zoompan matrix being used at all (see comment 5) so when you reapply the zoomAndPan attribute the zoom state will reset to a unit scale without panning.

Comment 13

[Duncan Loveday]

I worked around this by changing the size of the viewbox, e.g. to zoom in by a factor of 2 make set the viewbox to half the current size. That seemed to cause a change in scaling even with zoomAndPan="disable".

Or to be fully accurate, what I was doing was doubling currentScale, doubling the size of the <EMBED> containing the SVG whilst NOT increasing the size of the viewbox. Whilst with Adobe and Opera I double currentScale, double the size of the containing <EMBED> and double the size of the viewbox.

Comment 14

[Robert Longson [:longsonr]]

Attachment: patch

Comment 15

[Robert Longson [:longsonr]]

checked in http://hg.mozilla.org/mozilla-central/rev/c9d886710915