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

Issue 738022 link

Starred by 4 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

getBoundingClientRect reports double size for foreignObject children on a HiDPI monitor

Reported by yurivk...@gmail.com, Jun 29 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0

Steps to reproduce the problem:
0. Find an X11/GNU/Linux machine with a HiDPI monitor.

$ xdpyinfo | grep -B2 resolution
screen #0:
  dimensions:    3840x2160 pixels (508x286 millimeters)
  resolution:    192x192 dots per inch

1. Create an HTML document.
2. Add an `svg` child element to its body.
3. Add a `foreignObject` child element to the `svg` element.
4. Add any HTML child element to the `foreignObject` element.
5. Attempt to measure the rendered size of that HTML element by invoking its `getBoundingClientRect`.

What is the expected behavior?
The position and size of the element are reported in CSS pixels, consistent with how they are reported for an HTML element outside SVG. The two sizes in the test case should be identical or very close.

What went wrong?
The position and size seem to be reported in physical device pixels. On my machine, the HTML-only `div` is sized 79.14×18.5, while the `div` in `foreignObject` in `svg` is sized 158.3×36, about twice as large in each dimension.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 59.0.3071.115 (Official Build) (64-bit)  Channel: stable
OS Version: Ubuntu 16.04
Flash Version: Shockwave Flash 26.0 r0

In Firefox 54, both elements are sized 72×21.

In Chromium 61.0.3145.0 (Developer Build) (64-bit), the problem persists.
 
test.html
967 bytes View Download

Comment 1 by kochi@chromium.org, Jun 30 2017

Components: Blink>Layout
Labels: Needs-Feedback
Tested this issue using latest stable #59.0.3071.115 on Win 10, Mac 10.12.5 and Linux Ubuntu 14.04 and observed div and foreignObject` in `svg are showing same size.

@yurivkhan: Could you please find the attached screenshot and let us know your observations for further triaging of the issue.

Thanks!!
Screenshot (6).png
67.5 KB View Download
@sandeepkumars: That screenshot looks like usual 96 dpi. I believe the problem specifically manifests at 192 dpi and other high pixel densities, and possibly depends on the windowing system.

Please, when triaging this bug, keep step 0 in mind.
Project Member

Comment 4 by sheriffbot@chromium.org, Jul 6 2017

Cc: sandeepkumars@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 5 by e...@chromium.org, Jul 6 2017

Components: -Blink>Layout Blink>SVG
Confirmed.

Comment 6 Deleted

Comment 7 by f...@opera.com, Jul 6 2017

Status: Available (was: Untriaged)
Labels: BugSource-User PaintTeamTriaged-20170707
Any update on this? getBoundingClientRect still returns values that are not properly scaled with devicePixelRatio.
Cc: chrishtr@chromium.org wangxianzhu@chromium.org f...@opera.com
The current situation is that the SVGForeignObject returns values that are zoomed by the current zoom factor, while the HTML div does not (reports unzoomed values). On platforms not using hidpi-as-zoom (Mac and Android) the situation may well be different.

So basically it looks like the problem remains despite lots of fixes for foreign object recently.
It seems strange that SVGForeignObjects would just act differently. Is there a reason for this disparity or is it simply a bug? If the latter, is the root cause complex and hard to solve, or has there just not been cycles dedicated to this issue?

Comment 12 by f...@opera.com, Jun 8 2018

foreignObject is special (not the good kind.) In this case likely because it exists within an <svg>, and thus are subjected to special handling when it comes to zooming. Remains to be seen if this issue stems from that though of course, but it seems quite likely. Definitely a bug though.
 Issue 882899  has been merged into this issue.

Sign in to add a comment