SVG with no intrinsic size is shown too big when viewed standalone on HiDPI screen
Categories
(Core :: SVG, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox111 | --- | wontfix |
firefox112 | --- | wontfix |
firefox113 | --- | fixed |
People
(Reporter: giuseppe.bilotta, Assigned: emilio)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0
Steps to reproduce:
Open an SVG with no intrinsic size to be viewed standalone when using a HiDPI monitor.
Actual results:
The SVG is shown larger than the window, as if the scaling factor was being applied twice.
Expected results:
The SVG should have been scaled to fit within the viewport of the window. This is the expected behavior, and is also followed by older versions of Firefox (tested ESR 102).
Reporter | ||
Comment 1•2 years ago
|
||
This is just an example SVG that can be used to verify the issue.
Comment 2•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::SVG' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 3•2 years ago
|
||
If this is a regression perhaps you could use mozregression to find a regression range.
Reporter | ||
Comment 4•2 years ago
|
||
Hello Robert,
thanks for the recommendation. I was able to bisect the issue via mozregression. The last log is:
10:07.39 INFO: Narrowed integration regression window from [cb7c4d0b, d62480e6] (3 builds) to [cb7c4d0b, 6e1cbabc] (2 builds) (~1 steps left)
10:07.39 INFO: No more integration revisions, bisection finished.
10:07.39 INFO: Last good revision: cb7c4d0b946209a2a3b05cd5a35e31fadaf55135
10:07.39 INFO: First bad revision: 6e1cbabce0af992a8ff5158959ac9dd69bea23a7
10:07.39 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cb7c4d0b946209a2a3b05cd5a35e31fadaf55135&tochange=6e1cbabce0af992a8ff5158959ac9dd69bea23a7
The changeset seems relevant, as it's HiDPI-related changes that close https://bugzilla.mozilla.org/show_bug.cgi?id=1773342
Comment 5•2 years ago
|
||
Setting Regressed by
field after analyzing regression range found by mozregression in comment #4.
Comment 6•2 years ago
|
||
:emilio, since you are the author of the regressor, bug 1773342, could you take a look? Also, could you set the severity field?
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 7•2 years ago
|
||
Can you attach your about:support
information? What desktop environment are you on? Also if you have any interesting settings that'd be super useful.
Also to confirm, do you see the issue on something like this?
data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg"><rect width="100" height="100" fill="green"/></svg>
If not, can you provide a link that shows the issue on your setup? Thanks.
Updated•2 years ago
|
Reporter | ||
Comment 8•2 years ago
|
||
I'm on Debian unstable, X11, using awesomwm as WM. Monitor is HiDPI and correctly detected. HiDPI scaling is controlled by the Xft/DPI XSETTINGS that is set to 196608 raw (i.e. 192). Setting it to 96 (or removing the setting) puts Firefox back into “normal DPI” mode and the issue disappears (although obviously the UI then becomes too tiny to be usable; also other GTK apps won't scale either). BTW this means that the effect can be easly reproduced (at least on X11) by temporarily setting XSETTINGS' Xft/DPI to the above mentioned value (or probably by requesting a 2X scaling in whatever DE this is being tested on)
Your example appears normal (although it's hard to tell if the rectangle is actually 100x100 or 200x200). Adding a viewBox="0 0 100 100"
shows the issue very easily.
I think that without viewBox the sizing is correct because setting the rectangle dimensions to 1900 and 1000 nearly fills up the screen, which is what I would expect for an SVG being painted on a 4K screen at 2x scaling. So the issue seems to be with the viewBox handling to be specific.
(If the about:config is necessary I can attach it separately.)
Assignee | ||
Comment 9•2 years ago
|
||
Okay, so:
data:image/svg+xml,<svg viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg"><rect width="100" height="100" fill="green"/></svg>
Shows the issue for you, let me try to repro. Off-hand I can't repro on Plasma+Wayland, but let me try with something closer to your set-up.
Assignee | ||
Comment 10•2 years ago
|
||
This trivially reproduces with ui.textScaleFactor=150 or so.
This needs to match ImageDocument::GetZoomLevel, for the math here to
work out.
Assignee | ||
Updated•2 years ago
|
Comment 11•2 years ago
|
||
Comment 12•2 years ago
|
||
Backed out for causing reftest failures in foreignObject-zoom-01.svg
- Backout link
- Push with failures
- Failure Log
- Failure line: REFTEST TEST-UNEXPECTED-FAIL | layout/reftests/svg/moz-only/foreignObject-zoom-01.svg == layout/reftests/svg/moz-only/pass.svg | image comparison, max difference: 255, number of differing pixels: 600000
REFTEST TEST-UNEXPECTED-FAIL | layout/reftests/svg/moz-only/zoom-invalidation-01.svg == layout/reftests/svg/moz-only/pass.svg | image comparison, max difference: 255, number of differing pixels: 600000
Comment 13•2 years ago
|
||
Assignee | ||
Updated•2 years ago
|
Comment 14•2 years ago
|
||
Comment 15•2 years ago
|
||
Backed out 2 changesets (Bug 1824603) for causing browser_ImageDocument_svg_zoom.js CLOSED TREE
Log: https://treeherder.mozilla.org/logviewer?job_id=411222991&repo=autoland&lineNumber=13415
Backout: https://hg.mozilla.org/integration/autoland/rev/109449b20aadac2b88143dfe8938990c06080337
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Comment 16•2 years ago
|
||
Comment 17•2 years ago
|
||
bugherder |
Comment 18•2 years ago
|
||
Set release status flags based on info from the regressing bug 1773342
Updated•2 years ago
|
Description
•