svg text.getBBox() returns different size on headless mode
Reported by
hiroyuki...@gmail.com,
Oct 12 2017
|
|||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Example URL:
about:blank + tiny javascript
Steps to reproduce the problem:
1. please run chrome headless:
"C:/Program Files (x86)/Google/Chrome/Application/chrome.exe" --headless --disable-gpu --remote-debugging-port=9222 about:blank
2. connect to headless process (port 9222) by using devtools. And exec the following javascript to get text width:
var svgElm = document.createElementNS("http://www.w3.org/2000/svg", "svg");
document.body.appendChild(svgElm);
var textElm = document.createElementNS("http://www.w3.org/2000/svg", "text");
textElm.textContent = 'h';
svgElm.appendChild(textElm);
textElm.getBBox();
And test on normal (not-headless) mode and compare getBBox() result.
3. getBBox() returns different value:
normal mode: SVGRect {x: 0, y: -17, width: 9.890625, height: 24}
headless mode: SVGRect {x: 0, y: -14, width: 8, height: 17}
What is the expected behavior?
textElm.getBBox() result is same.
What went wrong?
textElm.getBBox() result is different.
Does it occur on multiple sites: N/A
Is it a problem with a plugin? N/A
Did this work before? N/A
Does this work in other browsers? N/A
Chrome version: 61.0.3163.100 (Official Build) （32 ビット） (cohort: Stable) Channel: stable
OS Version: 10.0
Flash Version:
,
Oct 13 2017
Adding Internals>Headless component. Requesting someone from Headless Chrome team to look into this issue.
,
Oct 15 2017
Thanks for providing the steps to reproduce!
I also get different values in Linux
Headless: SVGRect {x: 0, y: -14, width: 8, height: 17}
Non-Headless: SVGRect {x: -1, y: -14, width: 10, height: 17}
The interesting thing is that Headless is consistent across platforms, while non-headless isn't
Adding SVG in case they could know what's going on.
,
Oct 16 2017
5.40625 vs. 5.4140625 is issue 757436 (LayoutUnit precision), so we can ignore that in this context. I'd start by checking the font settings. Part of what's seen in c#1 can probably be explained by differences because of locale (different generic fonts.)
,
Oct 23 2017
Back to the Headless team because the font fallback seems to be the issue.
,
Oct 24
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by hiroyuki...@gmail.com
, Oct 13 2017please load attached 774018.html on (normal and headless mode) and check console: result on my environment is: ---------------------------------------------------- // normal: font-family: initial: 12: 12 774018.html:16 font-family: serif: 12: 12 774018.html:18 font-family: Meiryo: 12: 12 774018.html:20 font-family: Arial: 12: 12 // headless: font-family: initial: 5.40625: 5.4140625 774018.html:16 font-family: serif: 5.40625: 5.4140625 774018.html:18 font-family: Meiryo: 12: 12 774018.html:20 font-family: Arial: 5.40625: 5.4140625 ---------------------------------------------------- * not only getBBox() but also getComputedTextLength() returns different value on (normal and headless mode). * only {font-family = 'Meiryo'}, result is same on (normal and headless mode).940 bytes
940 bytes View Download