1284798 - SVG without viewport incorrectly stretches when used as border image, in e10s-disabled profiles

Status: RESOLVED DUPLICATE of bug 1290782

(Core :: SVG, defect)

Description

[Sebastian Zartner [:sebo]]

When an SVG image without viewport (i.e. without width and height) is used as border image, it is incorrectly stretched to the border image area.

SVGs without viewport used as border images should be displayed the same as SVGs having a viewport.

Sebastian

Comment 1

[Sebastian Zartner [:sebo]]

Attachment: SVG without viewport

Comment 2

[Sebastian Zartner [:sebo]]

Attachment: SVG 60 pixels

Comment 3

[Sebastian Zartner [:sebo]]

Attachment: test case

This is a test case showing an incorrectly stretched SVG border image without viewport and a correctly stretched SVG border image having a viewport for reference.

Sebastian

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Sebastian Zartner [:sebo] from comment #0)
> SVGs without viewport used as border images should be displayed the same as
> SVGs having a viewport.

I don't think that's true, in general.

In your "no viewport" case here, the only sizing information is percentage-based -- so what we paint in each quadrant depends entirely on the dimensions that we use for the "fake" viewport for the SVG image under the hood, as you can see if you load the image directly in a browser and change its size.  You seem to be assuming that we should treat the SVG image as if it were square, but there's no underlying reason that we should do that.

Note also that, for comparison, Chrome doesn't render the two examples the same.

We do have *a* bug here, though -- if I load the test case, and then resize my browser, and then reload, the rendering changes. That is definitely broken.

Comment 5

[Daniel Holbert [:dholbert]]

(Going into a bit more detail:  if the testcase involved four squares each of which were 25% across and 25% tall, *then* the image should render the same regardless of whether there's a viewport, I think.  Or even ellipses with rx=25%  ry=25%, I think.  But with circles, it very much depends on the viewport, because the 25% radius is resolved with respect to the length of the SVG viewport's hypotenuse (imaginary line going from upper left to bottom right corner).  So they end up being circles, even in a rectangular viewport -- which means the circles will overlap & stomp on each other in one direction or another, as you can see if you load the testcase directly in a browser.)

Comment 6

[Sebastian Zartner [:sebo]]

(In reply to Daniel Holbert [:dholbert] from comment #4)
> (In reply to Sebastian Zartner [:sebo] from comment #0)
> > SVGs without viewport used as border images should be displayed the same as
> > SVGs having a viewport.
> 
> I don't think that's true, in general.
>
> ...
>
> You seem to be assuming that we should treat the SVG image
> as if it were square, but there's no underlying reason that we should do
> that.

You're right, that was a wrong assumption based on what I saw when opening the file in Inkscape.

> Note also that, for comparison, Chrome doesn't render the two examples the
> same.

Yes. Though Chrome/Opera as well as IE/Edge also render the SVG without viewport significantly different than Firefox (though consistent across them), which lets me wonder whether there's a different bug.
As far as I can see they use the border image area as the image's viewport (and tile the image accordingly) while Firefox uses the size of each slice (and duplicates the image for each slice).
So, while my inital asumption of having a square viewport is wrong, the summary still seems to be valid.

> We do have *a* bug here, though -- if I load the test case, and then resize
> my browser, and then reload, the rendering changes. That is definitely
> broken.

I can't reproduce this on Windows 7. Can you file a new bug for that?

Sebastian

Comment 7

[Sebastian Zartner [:sebo]]

Attachment: SVG without viewport including ellipses

Comment 8

[Sebastian Zartner [:sebo]]

Attachment: test case

This is an adjusted test case better visualizing the differences between Gecko and other engines according to the insights gained in comment 6.

Sebastian

Comment 9

[Liz Henry (:lizzard) (relman/hg->git project)]

Regression in 48 from bug 619500

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to Sebastian Zartner [:sebo] from comment #6)
> (In reply to Daniel Holbert [:dholbert] from comment #4)
> > We do have *a* bug here, though -- if I load the test case, and then resize
> > my browser, and then reload, the rendering changes. That is definitely
> > broken.
> 
> I can't reproduce this on Windows 7. Can you file a new bug for that?

I will -- though, I actually am seeing pretty-bad graphical corruption throughout the browser in today's Nightly, so it's possible the thing I was seeing yesterday was just a form of that.

Could you clarify what (if anything) is still broken here, from your perspective? Your new testcase still labels two things "incorrect", and I don't see why they are incorrect.

Comment 11

[Daniel Holbert [:dholbert]]

(I've spun off bug 1284798 for the resize issue that I mentioned in comment 4.  I've confirmed that it's unrelated to the graphical corruption that I mentioned.)

Comment 12

[Daniel Holbert [:dholbert]]

[sorry, bug # typo in comment 11 -- reposting w/ typo corrected:]

I've spun off bug 1285320 for the resize issue that I mentioned in comment 4.  I've confirmed that it's unrelated to the graphical corruption that I mentioned.

Comment 13

[Sebastian Zartner [:sebo]]

Attachment: Incorrect test case rendering

(In reply to Daniel Holbert [:dholbert] from comment #10)
> Could you clarify what (if anything) is still broken here, from your
> perspective? Your new testcase still labels two things "incorrect", and I
> don't see why they are incorrect.

In your screencast from bug 1285320 the rendering actually looks like expected and I wondered why it looks different for me. I've created a new profile (using Nightly 2016-07-07) and with it I also get your rendering (including the issue from bug 1285320).
Therefore I've attached a screenshot of what I'm seeing in the other profile. I still need to investigate why it looks different in that profile (therefore keeping the ni).

Also, the border image with the ellipses looks ok to me now. I can't say if it's different after the Nightly update today or whether I accidentally checked this in Firefox 47.0.

Comment 14

[Sebastian Zartner [:sebo]]

Found out the cause: I had e10s disabled in that profile. After enabling it the issue is gone.
Because I expect e10s to land in stable soon, there's probably not much reason to fix this for the e10s-disabled case, but I let you decide whether to keep this bug open or close it as WONTFIX.

Sebastian

Comment 15

[Daniel Holbert [:dholbert]]

Thanks for clarifying. I can confirm that e10s/non-e10s profiles render the first part of your testcase differently (and the non-e10s one looks more broken).

> Because I expect e10s to land in stable soon, there's probably not much reason to fix this for the e10s-disabled case

Nah, still worth tracking this and figuring out what's going on.

Comment 16

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Here's a simpler testcase for the main issue that we've settled on here.

In a no-e10s profile, it shows splashes of the wrong color(s) in the upper-left, upper-right, and bottom-left corners (much like in sebo's screenshot).  It should show only a single color per corner, as it does in an e10s-enabled profile (and in Chrome).

Comment 17

[Kevin Chen[:kechen] (UTC + 8)]

I think the problem of this bug is the same as Bug 1290782.
The current patch in Bug 1290782 can also solve the problem.