fix(popover): account for css zoom in positioning by caspinos · Pull Request #31426 · ionic-team/ionic-framework

caspinos · 2026-09-04T14:55:13Z

Issue number: resolves #30919

Supersedes #31047, which this builds on. @KanhaiyaPandey is credited as co-author on the commit.

What is the current behavior?

When a CSS zoom other than 1 applies to the popover, ion-popover renders incorrectly: it is positioned away from its trigger, and with size="cover" it is given the wrong width. This affects a documented workflow — adjusting the html zoom is the approach Ionic's documentation recommends for dynamic font scaling on Chrome for Android.

The zoom factor is effectively applied twice. Geometry APIs (getBoundingClientRect() on the trigger, content and arrow, plus clientX/clientY for reference="event") report values in the zoomed coordinate space. Those values are written straight into the inline top/left/--width styles on .popover-content, which are interpreted in the unzoomed layout space and then re-scaled by the browser.

What is the new behavior?

The effective zoom is read from the popover's own context via currentCSSZoom, not from document.documentElement. This picks up a zoom applied anywhere above the popover and accounts for zoom accumulated across several ancestors. Where the property is unavailable, it falls back to the ratio between the element's bounding rect and its offsetWidth; differences below a small tolerance are treated as no zoom, since offsetWidth is integer-rounded and would otherwise report a phantom zoom.
Every rect-derived measurement is normalized by that factor: trigger and content rects, arrow dimensions, the size="cover" width, and the pointer coordinates used by reference="event".
innerWidth/innerHeight are scaled into the same space. They are not affected by CSS zoom, so leaving them alone made the offscreen adjustment clamp against a viewport larger than the space actually available, letting the popover render past the edge of the screen.
Behavior is unchanged when no zoom is applied: the detected factor is exactly 1 and every normalization is a division by 1.

This mirrors how Floating UI addressed the same problem in floating-ui/floating-ui#3492 — Element.currentCSSZoom as both the value and the feature detector, with a default of 1 on engines that lack it. Their fix also had to scale the overflow bounds inside detectOverflow(), which is the same class of issue as the innerWidth/innerHeight point above.

Does this introduce a breaking change?

Yes
No

The new zoom parameters on the popover positioning helpers are optional and default to 1. Those helpers are internal to the component and are not part of the public API.

Other information

Tests

Eight E2E tests in core/src/components/popover/test/zoom/, covering the review points raised on #31047:

Scenario	Covers
Zoom on `body`; accumulated zoom (`html` 1.2 × `body` 1.25)	zoom applied at levels other than `documentElement`
`size="cover"` width matches the trigger	sizing, not just positioning
`reference="event"` anchors to the pointer	pointer coordinates
Arrow centred on the trigger (ios)	arrow positioning
Popover stays within the viewport	offscreen adjustment
Zoomed out (`0.8`) and zoomed in (`1.5`)	factors either side of 1

All eight fail against main and pass with this change, so each one covers the regression rather than merely passing.

These are functional assertions rather than screenshots: what is being verified is the popover's geometry relative to its trigger, and both boxes are read in the same coordinate space, so the relationship holds at any zoom level. No screenshot baselines are added.

Unit tests in core/src/components/popover/test/util.spec.ts cover the zoom detection itself — the currentCSSZoom path, the offsetWidth fallback, the rounding tolerance — and the normalization of content, trigger and arrow measurements.

Verification

The spec suite passes in full: 82 files, 714 tests, no failures.

The zoom tests are not skipped for any browser and pass on all three browser projects — Chromium, Firefox and WebKit — in both ios and md modes. Assertions use a 2px tolerance to absorb sub-pixel differences between engines.

When a CSS `zoom` other than 1 applies to the popover, geometry APIs like `getBoundingClientRect()` and pointer `clientX`/`clientY` report values in the zoomed coordinate space, while the inline `top`/`left`/`--width` styles the popover sets are interpreted in the unzoomed layout space and re-scaled by the browser. Applying the zoom factor twice placed the popover in the wrong location and, with `size="cover"`, gave it the wrong width. Read the effective zoom from the popover's own context via `currentCSSZoom`, so a zoom applied anywhere above it is picked up and accumulated zoom across ancestors is handled, falling back to the ratio between the bounding rect and `offsetWidth` where that property is unavailable. Normalize every rect-derived measurement by it: the trigger and content rects, the arrow dimensions, the `size="cover"` width, and the pointer coordinates used by `reference="event"`. `innerWidth`/`innerHeight` are not affected by CSS `zoom`, so scale them into the same space as well. Otherwise the offscreen adjustment clamps against a viewport larger than the space actually available and the popover can render past the edge of the screen. closes ionic-team#30919 Co-authored-by: KanhaiyaPandey <kanhaiyapandey2232@gmail.com> Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014em3LPxMPQRPufMRz5i7so

vercel · 2026-09-04T14:55:17Z

@claude is attempting to deploy a commit to the Ionic Team on Vercel.

A member of the Team first needs to authorize it.

Copilot

🟢 Approval recommended

The zoom normalization approach is consistently applied and is backed by targeted unit/E2E coverage; only a minor naming typo remains.

Pull request overview

This PR fixes ion-popover positioning/sizing when CSS zoom is applied by normalizing geometry/pointer measurements into the unzoomed (layout) coordinate space, preventing the zoom factor from being effectively applied twice.

Changes:

Add getElementCSSZoom (using currentCSSZoom with an offsetWidth fallback) and thread a zoom factor through popover positioning/sizing helpers.
Normalize trigger/content/arrow rect measurements, reference="event" pointer coordinates, and viewport bounds (innerWidth/innerHeight) by the detected zoom factor in both MD and iOS enter animations.
Add E2E + unit coverage for zoomed scenarios (including accumulated zoom across ancestors, size="cover", reference="event", and iOS arrow positioning).

File summaries

File	Description
core/src/components/popover/utils.ts	Introduces zoom detection and normalizes rect-derived measurements/pointer coordinates in popover helpers.
core/src/components/popover/animations/md.enter.ts	Applies zoom normalization for MD positioning and viewport clamping.
core/src/components/popover/animations/ios.enter.ts	Applies zoom normalization for iOS positioning, arrow sizing, and viewport clamping.
core/src/components/popover/test/zoom/popover.e2e.ts	Adds functional E2E assertions validating popover geometry under various zoom setups.
core/src/components/popover/test/zoom/index.html	Adds a zoomed test fixture page with multiple trigger/popover configurations.
core/src/components/popover/test/util.spec.ts	Adds unit tests for zoom detection and zoom-normalized dimension helpers.

Review details

Files reviewed: 6/6 changed files
Comments generated: 1
Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

KanhaiyaPandey · 2026-09-04T16:23:39Z

Thanks @caspinos for taking this forward and for the detailed investigation.

vercel · 2026-09-10T18:10:51Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
ionic-framework	Ready	Preview	Sep 10, 2026 6:16pm UTC

thetaPC · 2026-09-10T16:51:24Z

+
+  /**
+   * `currentCSSZoom` exposes the exact effective zoom of an element
+   * (Chromium 126+). When available we use it directly.


currentCSSZoom landed in Chrome/Edge 128, not 126 as shown on MDN.

Suggested change

* (Chromium 126+). When available we use it directly.

* (Chromium 128+). When available we use it directly.

thetaPC · 2026-09-10T17:01:55Z

+    /**
+     * `offsetWidth` is rounded to an integer while the bounding rect is not,
+     * so the ratio is rarely exactly 1 even when no zoom is applied. Treat
+     * sub-pixel differences as "no zoom" so that unzoomed popovers are not
+     * shifted by the rounding error. A real zoom deviates far more than this.
+     */


The ratio is approximate rather than exact, and the comment should say so. offsetWidth is integer rounded, so the detected factor keeps a small error once a real zoom is present: on WebKit I measured 1.5033 against an actual 1.5 on a 56px popover.

It is harmless at realistic widths and well inside the 2px tolerance the e2e tests use. Worth writing down because the tolerance only snaps the unzoomed case to exactly 1, so nothing bounds the error in the zoomed case, and a later change that tightens an assertion against the detected zoom would be surprised by it.

Suggested change

/**

* `offsetWidth` is rounded to an integer while the bounding rect is not,

* so the ratio is rarely exactly 1 even when no zoom is applied. Treat

* sub-pixel differences as "no zoom" so that unzoomed popovers are not

* shifted by the rounding error. A real zoom deviates far more than this.

*/

/**

* `offsetWidth` is rounded to an integer while the bounding rect is not,

* so the ratio is rarely exactly 1 even when no zoom is applied. Treat

* sub-pixel differences as "no zoom" so that unzoomed popovers are not

* shifted by the rounding error. A real zoom deviates far more, though

* the same rounding leaves the detected factor approximate.

*/

thetaPC · 2026-09-10T17:18:14Z

+     * `document.documentElement`, otherwise a zoom applied lower in the tree is
+     * missed entirely.
+     */
+    test.describe('zoom applied at other levels of the tree', () => {


Please add a case where the zoom wraps only the trigger, on top of what is here. The existing cases all put it on html or body, an ancestor of both elements, so the popover and the trigger never end up under different zooms. That split is what popoverController.create() produces by default, since the overlay is appended to ion-app.

<style> .panel { zoom: 1.5; } </style> <div class="panel"> <button id="trigger">Trigger</button> </div> <ion-popover trigger="trigger"> <ion-content class="ion-padding">Content</ion-content> </ion-popover>

zoomedPage() only takes the styles, so this needs its own markup. It already passes on your branch, so it guards a regression rather than fixing anything: reading the factor from contentEl instead of document.documentElement is what makes it hold.

thetaPC · 2026-09-10T17:45:44Z

+   * `currentCSSZoom` exposes the exact effective zoom of an element
+   * (Chromium 126+). When available we use it directly.
+   */
+  const currentCSSZoom = (el as unknown as { currentCSSZoom?: number }).currentCSSZoom;


currentCSSZoom is already declared on Element in lib.dom.d.ts, both in the TypeScript 6.0.3 the repo is on and in the copy Stencil 4.44.2 bundles, so the cast is not needed. Lints and typechecks clean without it.

Suggested change

const currentCSSZoom = (el as unknown as { currentCSSZoom?: number }).currentCSSZoom;

const currentCSSZoom = el.currentCSSZoom;

Keep the typeof guard below either way. The lib declares it as a required number, but WebKit has not shipped it and returns undefined at runtime, so that check is load-bearing despite what the type says.

thetaPC · 2026-09-10T18:25:03Z

+ */
+configs({ modes: ['ios'], directions: ['ltr'] }).forEach(({ title, config }) => {
+  test.describe(title('popover: zoom'), () => {
+    test('should centre the arrow on the trigger when a zoom is applied', async ({ page }) => {


Please extend this to the other sides. calculateArrowPosition branches per side and each branch now runs on zoom-normalized dimensions, but only the default bottom is covered. /popover/test/arrow/ has a trigger per side to model it on, and these should stay functional rather than screenshots.

The assertion here only holds for top and bottom though. The side positions centre the arrow vertically instead, so they need a different expectation.

thetaPC · 2026-09-10T18:25:10Z

+ */
+configs({ modes: ['ios'], directions: ['ltr'] }).forEach(({ title, config }) => {
+  test.describe(title('popover: zoom'), () => {
+    test('should centre the arrow on the trigger when a zoom is applied', async ({ page }) => {


Suggested change

test('should centre the arrow on the trigger when a zoom is applied', async ({ page }) => {

test('should center the arrow on the trigger when a zoom is applied', async ({ page }) => {

caspinos requested a review from a team as a code owner September 4, 2026 14:55

caspinos requested review from OS-jacobbell and a lite review from Copilot September 4, 2026 14:55

github-actions Bot added the package: core @ionic/core package label Sep 4, 2026

Copilot started reviewing on behalf of caspinos September 4, 2026 14:55 View session

Copilot AI reviewed Sep 4, 2026

View reviewed changes

Comment thread core/src/components/popover/utils.ts

vercel Bot deployed to Preview September 10, 2026 18:16 View deployment

thetaPC requested changes Sep 10, 2026

View reviewed changes

Navigation Menu

Uh oh!

fix(popover): account for css zoom in positioning - #31426

fix(popover): account for css zoom in positioning#31426
caspinos wants to merge 1 commit into
ionic-team:mainfrom
caspinos:claude/ionic-issue-30919-ahirt4

caspinos commented Sep 4, 2026

Uh oh!

vercel Bot commented Sep 4, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

KanhaiyaPandey commented Sep 4, 2026

Uh oh!

vercel Bot commented Sep 10, 2026 •

edited

Loading

Uh oh!

thetaPC Sep 10, 2026

Uh oh!

thetaPC Sep 10, 2026

Uh oh!

thetaPC Sep 10, 2026

Uh oh!

thetaPC Sep 10, 2026

Uh oh!

thetaPC Sep 10, 2026

Uh oh!

thetaPC Sep 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

	* (Chromium 126+). When available we use it directly.
	* (Chromium 128+). When available we use it directly.

	const currentCSSZoom = (el as unknown as { currentCSSZoom?: number }).currentCSSZoom;
	const currentCSSZoom = el.currentCSSZoom;

	test('should centre the arrow on the trigger when a zoom is applied', async ({ page }) => {
	test('should center the arrow on the trigger when a zoom is applied', async ({ page }) => {

Uh oh!

Conversation

caspinos commented Sep 4, 2026

What is the current behavior?

What is the new behavior?

Does this introduce a breaking change?

Other information

Uh oh!

vercel Bot commented Sep 4, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟢 Approval recommended

Uh oh!

Uh oh!

KanhaiyaPandey commented Sep 4, 2026

Uh oh!

vercel Bot commented Sep 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thetaPC Sep 10, 2026

Choose a reason for hiding this comment

Uh oh!

thetaPC Sep 10, 2026

Choose a reason for hiding this comment

Uh oh!

thetaPC Sep 10, 2026

Choose a reason for hiding this comment

Uh oh!

thetaPC Sep 10, 2026

Choose a reason for hiding this comment

Uh oh!

thetaPC Sep 10, 2026

Choose a reason for hiding this comment

Uh oh!

thetaPC Sep 10, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

vercel Bot commented Sep 10, 2026 •

edited

Loading