New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 848748 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug

Blocked on: View detail
issue 757196
issue 807788



Sign in to add a comment

SVG line length does not scale smoothly with zoom

Reported by neil.ger...@cba.mit.edu, Jun 1 2018

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36

Steps to reproduce the problem:
1. Attached test case svgtest.html draws an SVG overflow line to an absolute div location.
2. Line correctly ends at div if SVG width=height=2
3. Line ends incorrectly if SVG width=height=1

What is the expected behavior?
Line should end at the div.

What went wrong?
Chrome in Windows 10 draws the SVG line incorrectly if the SVG width=height=1, but draws it correctly if width=height=2.

Chrome in Ubuntu 16.04, and Firefox in Windows 10 and Ubuntu 16.04, draw the line correctly for width=height=1 or 2.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 66.0.3359.181  Channel: stable
OS Version: 10
Flash Version:
 
svgtest.html
1.0 KB View Download
svgtest.png
127 KB View Download
Cc: fmalita@chromium.org f...@opera.com
Labels: OS-Android OS-Chrome OS-Linux OS-Mac
Status: Available (was: Unconfirmed)
Summary: SVG line length does not scale smoothly with zoom (was: Windows error in rendering SVG)
This issue is not Windows vs Linux, the issue is with zoom only scaling the SVG line length in integral steps. It manifests on all platforms as you adjust zoom.

I presume that the reporter has Windows Display Properties set to modify the effective screen DPI.

To be honest, it always struck me as weird that SVG content would escape the SVG width/height.
I will test Windows DPI settings.

Note that this example is with SVG and browser zoom at defaults, so there should not be any scaling. In testing, this behavior has been seen only in Chrome on Windows.

And note that the test case sets svg.style.overflow = 'visible'; disabling clipping to the viewBox is a choice. In this case it's because the use case this is from has an SVG layer that's dynamically sized and not known in advance.

Comment 3 by kbr@chromium.org, Jun 1 2018

Cc: kbr@chromium.org
Components: UI>HighDPI

Comment 4 by kbr@chromium.org, Jun 1 2018

Labels: -Pri-2 Pri-1
Can I bump this to P1? I'm sure there are many high priority bugs, but this one affects the entire user interface for MIT's in-browser CAD and fabrication system, http://mods.cba.mit.edu (see http://cba.mit.edu/about/index.html for some background on the group). See the attached working/broken screenshots, the latter from Windows.

Screenshot Working.png
153 KB View Download
Screenshot Broken.png
124 KB View Download

Comment 5 by kbr@chromium.org, Jun 1 2018

Labels: -Pri-1 Pri-2
Talking with the submitter, it sounds like they've already worked around this problem on their site using the workaround in the description. Since there's a workaround, downgrading to P2 again.

Comment 6 by f...@opera.com, Jun 4 2018

I guess this is the same underlying issue as issue 807788 (and issue 757196.)

Comment 7 by kbr@chromium.org, Jun 4 2018

Blockedon: 757196 807788
Owner: malaykeshav@chromium.org
Status: Assigned (was: Available)
malaykeshav@ please triage
Owner: ----
Status: Untriaged (was: Assigned)
This is related to scaling in blink. I dont know who the right person is for this issue.

Comment 10 by kbr@chromium.org, Jun 8 2018

Components: Blink>Paint
Can anyone from the Paint team provide advice so this doesn't slip through the cracks?

Why raise the priority if there is a workaround that does not harm, the content and the bug has existed for a very long time? The only way to keep it at the top of the agenda is to make it P1, but we have a lot of more important things without workarounds that we need to fix.

Comment 12 by kbr@chromium.org, Jun 8 2018

I downgraded it back to P2 after realizing that there was a workaround.

Comment 13 by f...@opera.com, Jun 11 2018

Status: Available (was: Untriaged)
Cc: est...@chromium.org
Owner: malaykeshav@chromium.org
Status: Assigned (was: Available)
malay, please triage.
Cc: -est...@chromium.org
Owner: ----
Status: (was: Assigned)
I dont know who works on SVG in blink. This is related to scaling in the web content.
Status: Available
Components: -UI>HighDPI

Sign in to add a comment