[Webkit-unassigned] [Bug 261109] New: etBoundingClientRect() reports wrong sizes for XHTML elements on page zoom

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Sep 4 03:40:18 PDT 2023


https://bugs.webkit.org/show_bug.cgi?id=261109

            Bug ID: 261109
           Summary: etBoundingClientRect() reports wrong sizes for XHTML
                    elements on page zoom
           Product: WebKit
           Version: Safari 16
          Hardware: Mac (Apple Silicon)
                OS: macOS 13
            Status: NEW
          Severity: Major
          Priority: P2
         Component: SVG
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: olexander.danilchenko at gmail.com
                CC: sabouhallawa at apple.com, zimmermann at kde.org

Created attachment 467537

  --> https://bugs.webkit.org/attachment.cgi?id=467537&action=review

Safari misplaces the tooltip that should be attached to the embedded XHTML element

Given a page with an SVG element with XHTML content embedded via <foreignObject/>, the getBoundingClientRect() method returns sizes that don't match the parent page viewport on zooming with Cmd +/-. It breaks the positioning of the elements next to the target element using the getBoundingClientRect(), which is essential for the various tooltips or outlines.
Instead, the getBoundingClientRect() should return the same values as if the element is not being embedded into the <foreignObject/>. That would match the behavior of Chrome and Firefox.

I was able to replicate the bugged behavior with additional logs in the sandbox - https://stackblitz.com/edit/stackblitz-starters-jh33b2?file=src%2FApp.tsx. Open it in Safari and try zooming the page with Cmd +/-. You'll see that the teal block will get misplaced. However, in Chrome or Firefox, the teal block will always be displayed right underneath the target orange XHTML block.

Here's the comparison table of the tooltip position values I get in Chrome and Safari for the XHTML block:
| Zoom level | Safari                               | Chrome                               |
|------------|--------------------------------------|--------------------------------------|
| -2         | { top: '45px', left: '0px' }         | { top: '60px', left: '0px' }         |
| -1         | { top: '51px', left: '0px' }         | { top: '60px', left: '0px' }         |
| 0          | { top: '60px', left: '0px' }         | { top: '60px', left: '0px' }         |
| 1          | { top: '69px', left: '0px' }         | { top: '60px', left: '0px' }         |
| 2          | { top: '75px', left: '0px' }         | { top: '60px', left: '0px' }         |
| 3          | { top: '90px', left: '0px' }         | { top: '60px', left: '0px' }         |


Meanwhile, such misplacement doesn't happen if I'm using getBoundingClientRect() on the plain <div/> located within a body of the page - https://stackblitz.com/edit/stackblitz-starters-lnhzg3?file=src%2FApp.tsx. The `top` and the `left` properties stay the same on an arbitrary zoom level.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230904/c4dfb6f5/attachment.htm>


More information about the webkit-unassigned mailing list