1312119 - The viewport for svg inside border-image is not properly updated on the element's dimensions change

Status: UNCONFIRMED

(Core :: SVG, defect)

Description

[Roman Komarov]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.101 YaBrowser/16.10.1.171 (beta) Yowser/2.5 Safari/537.36

Steps to reproduce:

Create a block with a border-image consisting of SVG that have media queries inside that target different viewport widths. Then apply this on elements with different widths and/or dynamic dimensions. See this example: http://codepen.io/kizu/pen/GjPYYz


Actual results:

The queries are not applied equally and look overall buggy.


Expected results:

The queries should apply to all parts of the border-image equally and for proper element sizes, look at the desired result in Webkit/Blink browsers.

Comment 1

[Loic]

I think it has improved after bug 1285320 which landed in 50+.
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=232d6b6ae7908041cdb09fff963990a1503d63d8&tochange=a517dfb9fc0b8512fba4fa28da989758f9347dc6


Roman, could you download Nightly and confirm the rendering is fixed or better.
https://www.mozilla.org/en-US/firefox/nightly/all/

Comment 2

[Roman Komarov]

Yep, just checked in 51.0a2, so much better, nice! Still managed to trigger the bug sometimes, mostly on the contenteditable block and on page zoom change sometimes.

Comment 3

[Roman Komarov]

Attachment: Demonstration of the bug

Just checked, the issue still reproduces for me on the test page for some of the width values, see screenshot attached (Fx 53.0.3)

Comment 4

[Loic]

Could you attach a new testcase with these values, please.

Comment 5

[Roman Komarov]

I think that's the same test case, but I forked it with some values that demonstrate some issues: https://codepen.io/kizu/pen/QgLXZj

Though, it maybe not that its the same issue that was when I've opened the issue, but if you'd still compare the page between different browsers you'll see the difference and what, for example, Chrome behaves there as expected, while in Fx I'm not sure how the engine matches the media queries inside the border image.

Comment 6

[Loic]

Indeed, the issue is visible with Nightly.
Kevin, could you check the testcase of the reporter and share your thoughts about the issue, it's still not fixed after your patch in bug 1285320.

Comment 7

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

Sorry I don't have any conclusion right now, It seems like we might have some errors in calculating media queries of SVG.
Daniel, do you have any thought on this?

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (from comment 5)

Here's a saved copy of Roman's testcase from comment 5, FWIW, so that we're not dependent on codepen for testing & testcase-archival purposes.

For the record:
 - I can't reproduce at my normal zoom-level in Linux Nightly -- I tried resizing the resizeable thing a bunch, and typing/deleting text in the contenteditable elements, and I never saw anything like Comment 3 where the top edges & side edges don't match.  I tested in Chrome, too, and I'm seeing consistent behavior in Nightly vs. Chrome.
 - However, if I zoom in once with Ctrl+, I *can* reproduce some weirdness -- different color in each of the 10px-by-10px corner-squares.
 - So I'll bet this is zoomlevel-dependent (and I'm guessing that the only way this affects the default zoom-level is if you've got a Retina Display, or another High-DPI configuration -- though if anyone has reproduced this with a non-retina display & without full-page-zoom, please comment).

Unfortunately my plate is pretty full with performance bugs at the moment, so since this isn't a regression, it's not critical enough for me to dive right in.  I'll hopefully circle back to this at some point, though.

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: screenshot of bug (in testcase 1, on linux, after zooming in once with Ctrl +)

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: testcase 2

Here's another testcase which I think gets at the same issue.

STR:

1. Load attached testcase.
2. Zoom in several times (using full-page zoom)

EXPECTED RESULTS:
The black border should get thicker proportional to how much you zoom in. It should continue to cover up the red.

ACTUAL RESULTS:
Black border remains roughly the same thickness. The red background gets revealed out from under it, as you zoom in more and more (as the element grows larger while the black border fails to grow).