606360 - Full-page-zoom scale factor is applied twice for SVG <image> elements

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Emil Ivanov]

http://svgvspng.com/

When zooming with Firefox 3.6.11 the svg is not resized at all.

With Firefox 4.0b8pre only half of the object is resized, looks wery weird.

This is working with Chrome 7 as expected.

Comment 1

[Daniel Holbert [:dholbert]]

specifically, Firefox & Chromium differ on the handling of this SVG file used at that URL:
  http://svgvspng.com/en.svg

When zoomed, Chromium increases the size of that SVG file, pushing some of it outside the browser viewport.

In Contrast, Firefox doesn't change the SVG rendering at all on full-page-zoom  -- it just leaves it occupying the full browser viewport, because the SVG has a viewBox attribute.

Firefox's behavior is correct, per the SVG spec -- we're keeping the SVG file's viewBox aligned with the browser's viewport (which is what you're supposed to do for SVG content that has a viewBox).

If you remove the viewBox attribute, we give the behavior that Emil expects -- we increase/decrease the size of the SVG as you zoom in/out.

So, this bug should be resolved INVALID, in my opinion.

Comment 2

[Robert Longson [:longsonr]]

The firefox 3.6.10 behaviour is correct so the png image should not change on zoom. This is a bug on trunk and my guess is that it's yet more fallout from bug 598798

Comment 3

[Robert Longson [:longsonr]]

Looks like we're going to need either to pass a flag to stop the zoom scaling occurring or inverse scale the GetImageTransform transform by the zoom scale factor something like this...

float cssPxPerDevPx = PresContext()->
 AppUnitsToFloatCSSPixels(PresContext()->AppUnitsPerDevPixel());

ctx->SetMatrix(GetImageTransform().Scale(cssPxPerDevPx, cssPxPerDevPx))

Comment 4

[Daniel Holbert [:dholbert]]

Ah, right -- apologies for the INVALID recommendation in comment 1.  I'd somehow missed the comparison vs. Firefox 3.6 in comment 0 -- I only noticed the comparison vs. chrome's (incorrect IMHO) behavior.

Setting as a regression from bug 598798, since I agree that's the likely cause.

Comment 5

[Daniel Holbert [:dholbert]]

(confirmed that this is a regression from bug 598798, with local file-revert)

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to comment #3)
> Looks like we're going to need either to pass a flag to stop the zoom scaling
> occurring or inverse scale the GetImageTransform transform by the zoom scale
> factor something like this...

The latter seems simpler.  Tested that, and it works -- patch with reftest coming up.

Comment 7

[Daniel Holbert [:dholbert]]

Requesting blocking. (This is a regression w.r.t. 1.9.2)

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: fix

This patch does what Robert suggested in comment 5 (except with a local variable to save AppUnitsPerDevPixel, since we use it multiple times in that function now).

This also removes an incorrect comment about the nonexistant variable "|destRect|" from this region of code -- that variable existed in an intermediate version of my patch for bug 598798, but not in the final version, and I forgot to remove the comment about it.  (It's regarding SVG-backed images, so even if it were accurate -- which I don't think it will be when bug 272288 lands -- it would want to come in as part of that bug's patches.)

Comment 9

[Emil Ivanov]

(In reply to comment #4)
> Ah, right -- apologies for the INVALID recommendation in comment 1.  I'd
> somehow missed the comparison vs. Firefox 3.6 in comment 0 -- I only noticed
> the comparison vs. chrome's (incorrect IMHO) behavior.
> 
> Setting as a regression from bug 598798, since I agree that's the likely cause.

Sorry Daniel i wasnt aware that there is a possibility for svg to prevent page zoom. I also thought that Chrome is doing it right because things usually works there and Chrome did what i expected to happen with the page when zooming.

Indeed there is a comparison with Firefox trunk and branch and Chrome, trunk as i said looks very weird compared to others.

Comment 10

[Robert Longson [:longsonr]]

It depends on how the browser has implemented page zoom.

Firefox implements it by pretending that the display resolution is greater or smaller. So say you have a 100dpi screen then zooming will pretend that is 90 or 110 dpi depending on which way you go. If the svg was 100px wide then 100px will seem smaller or larger as it occupies fewer real dots on the screen. If an svg drawing is 100% wide/high or uses a viewBox (which does something similar but more complicated) then it just scales inversely with the zoom and the whole effect is that it looks the same.

Chrome may have implemented zooming differently as there's no specification for how browsers zoom.

Note that we're not talking SVG pan/zoom here, for which there is a specification.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

For a regular HTML document you do not want zooming to induce scrollbars by increasing the apparent size of the viewport.

I can see that for SVG documents with viewBox we might want to increase the size of the viewport referenced by viewBox by the amount of fullzoom. It's definitely not good from a UX point of view for full-zoom to appear to not work. Someone file a new bug for that?

Comment 12

[Daniel Holbert [:dholbert]]

Hmm, good point.  Ok -- filed Bug 606612 on that.

Comment 13

[Daniel Holbert [:dholbert]]

http://hg.mozilla.org/mozilla-central/rev/93e55d98952d