advanced-camera-card

3 Commits

Author SHA1 Message Date

Author	SHA1	Message	Date
Matthijsanddermotduffy	299973a1fa	fix: size a newly selected grid cell in a single layout pass (#2730 ) Selecting a camera in `live.display.mode: grid` lands in two visible passes: the cell gets its 2-column width immediately but keeps its 1-row height for ~400 ms, and the rest of the grid only settles ~700 ms after the click (measured per-frame on `main`; v7.27.4 has the same two passes, v8's early position resolution just leaves the late height correction standing out as a lone vertical jump). Cause: a grid cell's height follows its content in the same style recalculation as its width (intrinsic media ratio, `dimensions.aspect_ratio`, or the unsized 16:9 reservation), but the slotted carousel carries an inline `max-height` from `MediaHeightController` (debounced 0.3 s + 0.1 s transition; it sizes the card outside grids). In a grid that cap can only ever delay growth: it pins the freshly widened cell at its old height until the debounce fires, and the correction then also rides the 300 ms `_throttledLayout`. `selectCell()`'s existing `forceReflow()` + `layout()` was already positioned to do this in one pass; the cap starves it of the final height. Fix: neutralize the cap on grid cells (`max-height: none !important`; important is needed to beat the inline style). Covers the live and viewer grids; non-grid behaviour is untouched. This also stops the cap clipping cells by their border width (it was measured on the slide's content box but applied to the cell's border box). Trade-off worth flagging: in the viewer grid a cell's carousel holds all of one camera's media. If those slides do not share one ratio, the cell now sizes to its tallest slide (letterboxing shorter ones, no re-layout per swipe) instead of tracking the selected one after a debounce. If you would rather leave the viewer untouched, the rule can be scoped to `::slotted(advanced-camera-card-live-carousel)` instead (live grid cells always hold exactly one slide); say so and I will rework the PR that way. Verification: - New browser test `tests/components/live/grid.browser.test.ts`: fails on any frame where the newly selected cell is selected-wide but still unselected-high. On `main` it fails with 22 such frames; with this change there are none: the click settles in a single frame (~28 ms), every cell at its final size and position. - `yarn run test`, `yarn run test:browser` (chromium, firefox and webkit for the new test), `yarn run lint`, `yarn run typecheck` pass. - No resize oscillation in a cramped viewport with an appearing/disappearing ancestor scrollbar (the #2306 scenario), on window resizes, or under a narrow-screen `grid_columns: 2` override; verified against a live HA 2026.8.3 dashboard (6 go2rtc cameras). --------- Co-authored-by: dermotduffy <dermot.duffy@gmail.com>	2026-08-30 17:33:48 -07:00
Matthijsanddermotduffy	e6bb0eb0e0	fix: claim pointer focus without a visible focus ring (#2733 ) Since `f240646` (#2639, first released in v8.0.0) the card claims focus on any `pointerdown` inside it, so that `key` triggers receive their keyboard events (`keyboard-state-manager.ts`). The claim is a script call, `element.focus({ preventScroll: true })`, and script-initiated focus comes with the browser's focus indicator: after a pointer press while focus was outside the card, the card matches `:focus-visible` and Chromium draws its default ring around the entire card (measured: `outline: auto 1px rgb(238, 238, 238)`, a bright line on a dark dashboard). The ring then persists until focus leaves the card, which users experience as a white border that appears intermittently when they click or tap the card. Ordinary dashboard cards are unaffected because they rely on the browser's native pointer focus, which shows no indicator. Isolated in the same browser, a plain `tabindex` element gains focus from a click without matching `:focus-visible`, while `focus()` from script does match it. v7 did not claim focus at all, so it never showed this. Change: pass the intent along with the claim: `element.focus({ preventScroll: true, focusVisible: false })`. This code path only runs for pointer interaction, where no indicator is wanted. Keyboard focus does not pass through it: tabbing to the card keeps its ring, and the `key` trigger support from #2639 is unchanged. Browsers without `FocusOptions.focusVisible` ignore the option and simply keep today's behaviour. (`focusVisible` is not yet in the bundled TypeScript DOM types, hence the small global augmentation.) Verification: - Unit test asserts the focus claim carries `focusVisible: false`. - Measured in Chromium 152 on a live dashboard: before, a pointer press on the card leaves it `:focus-visible` with the UA default ring; after, the same press focuses the card without one, and reaching the card with Tab still shows the ring. In the same browser, `focus({ focusVisible: false })` verifiably suppresses `:focus-visible` where a plain `focus()` sets it. - `yarn run test`, `yarn run test:browser` (chromium and firefox), `yarn run lint` and `yarn run typecheck` pass. The webkit browser run fails one focus test in this local environment, identically on unmodified `main`, so it is unrelated to this change. --------- Co-authored-by: dermotduffy <dermot.duffy@gmail.com>	2026-08-30 14:04:40 -07:00
Matthijsanddermotduffy	fc7e09952f	fix: vertically center icons within icon buttons (#2734 ) Menu icons sit visibly high inside their round buttons in the iOS companion app, and one pixel high everywhere else. The card's icon wrapper (`advanced-camera-card-icon`) is slotted into `ha-icon-button`, whose label renders slotted content inside a plain `<span>`. The wrapper is an `inline-block`, so it rides the text baseline and leaves the font's descender space underneath it: the span grows taller than the icon (measured: 24.5px around a 22.5px icon under Roboto), the button's flex layout centers the span, and the icon lands high by half the descent. That descent is a property of the active font, which is why the offset differs per platform: about 1px under Roboto, and about 2px when the font stack resolves to a system font, as on iOS, where it is clearly visible inside the round menu button background. Slotted Home Assistant icons do not show this because they are laid out block-level via `--ha-icon-display`, which the card already sets; the card's own wrapper element reintroduces the inline-block one level up. Change: lay the wrapper out block-level wherever it is slotted into `ha-icon-button` (`button.scss`, which also covers the submenu and next/previous controls). Block layout has no baseline, so the label span shrinks to exactly the icon and the icon centers. Verification: - The structure (flex button, label span, slotted icon) rebuilt standalone in Playwright Chromium and WebKit: with an inline-block icon the offset is 1px under Roboto and 1.75 to 2px under system fonts, in both engines; with a block icon it is 0.0px in every engine, font, and button size tried. - Measured on a live HA 2026.8.3 dashboard (45px menu buttons): before, every menu icon center sat 1px above its button center; after, 0.0px for both a standard menu button and a conditional `advanced-camera-card-menu-icon` element. - `yarn run test`, `yarn run test:browser` (chromium), `yarn run lint`, `yarn run typecheck` pass. --------- Co-authored-by: dermotduffy <dermot.duffy@gmail.com>	2026-08-30 12:11:10 -07:00

299973a1fa

fix: size a newly selected grid cell in a single layout pass (#2730 )

Selecting a camera in `live.display.mode: grid` lands in two visible
passes: the cell gets its 2-column width immediately but keeps its 1-row
height for ~400 ms, and the rest of the grid only settles ~700 ms after
the click (measured per-frame on `main`; v7.27.4 has the same two
passes, v8's early position resolution just leaves the late height
correction standing out as a lone vertical jump).

**Cause:** a grid cell's height follows its content in the same style
recalculation as its width (intrinsic media ratio,
`dimensions.aspect_ratio`, or the unsized 16:9 reservation), but the
slotted carousel carries an inline `max-height` from
`MediaHeightController` (debounced 0.3 s + 0.1 s transition; it sizes
the card outside grids). In a grid that cap can only ever delay growth:
it pins the freshly widened cell at its old height until the debounce
fires, and the correction then also rides the 300 ms `_throttledLayout`.
`selectCell()`'s existing `forceReflow()` + `layout()` was already
positioned to do this in one pass; the cap starves it of the final
height.

**Fix:** neutralize the cap on grid cells (`max-height: none
!important`; important is needed to beat the inline style). Covers the
live and viewer grids; non-grid behaviour is untouched. This also stops
the cap clipping cells by their border width (it was measured on the
slide's content box but applied to the cell's border box).

**Trade-off worth flagging:** in the *viewer* grid a cell's carousel
holds all of one camera's media. If those slides do not share one ratio,
the cell now sizes to its tallest slide (letterboxing shorter ones, no
re-layout per swipe) instead of tracking the selected one after a
debounce. If you would rather leave the viewer untouched, the rule can
be scoped to `::slotted(advanced-camera-card-live-carousel)` instead
(live grid cells always hold exactly one slide); say so and I will
rework the PR that way.

**Verification:**

- New browser test `tests/components/live/grid.browser.test.ts`: fails
on any frame where the newly selected cell is selected-wide but still
unselected-high. On `main` it fails with 22 such frames; with this
change there are none: the click settles in a single frame (~28 ms),
every cell at its final size and position.
- `yarn run test`, `yarn run test:browser` (chromium, firefox and webkit
for the new test), `yarn run lint`, `yarn run typecheck` pass.
- No resize oscillation in a cramped viewport with an
appearing/disappearing ancestor scrollbar (the #2306 scenario), on
window resizes, or under a narrow-screen `grid_columns: 2` override;
verified against a live HA 2026.8.3 dashboard (6 go2rtc cameras).

---------

Co-authored-by: dermotduffy <dermot.duffy@gmail.com>

2026-08-30 17:33:48 -07:00

Matthijsanddermotduffy

e6bb0eb0e0

fix: claim pointer focus without a visible focus ring (#2733 )

Since f240646 (#2639, first released in v8.0.0) the card claims focus on
any `pointerdown` inside it, so that `key` triggers receive their
keyboard events (`keyboard-state-manager.ts`). The claim is a script
call, `element.focus({ preventScroll: true })`, and script-initiated
focus comes with the browser's focus indicator: after a pointer press
while focus was outside the card, the card matches `:focus-visible` and
Chromium draws its default ring around the entire card (measured:
`outline: auto 1px rgb(238, 238, 238)`, a bright line on a dark
dashboard). The ring then persists until focus leaves the card, which
users experience as a white border that appears intermittently when they
click or tap the card.

Ordinary dashboard cards are unaffected because they rely on the
browser's native pointer focus, which shows no indicator. Isolated in
the same browser, a plain `tabindex` element gains focus from a click
without matching `:focus-visible`, while `focus()` from script does
match it. v7 did not claim focus at all, so it never showed this.

**Change:** pass the intent along with the claim: `element.focus({
preventScroll: true, focusVisible: false })`. This code path only runs
for pointer interaction, where no indicator is wanted. Keyboard focus
does not pass through it: tabbing to the card keeps its ring, and the
`key` trigger support from #2639 is unchanged. Browsers without
`FocusOptions.focusVisible` ignore the option and simply keep today's
behaviour. (`focusVisible` is not yet in the bundled TypeScript DOM
types, hence the small global augmentation.)

**Verification:**

- Unit test asserts the focus claim carries `focusVisible: false`.
- Measured in Chromium 152 on a live dashboard: before, a pointer press
on the card leaves it `:focus-visible` with the UA default ring; after,
the same press focuses the card without one, and reaching the card with
Tab still shows the ring. In the same browser, `focus({ focusVisible:
false })` verifiably suppresses `:focus-visible` where a plain `focus()`
sets it.
- `yarn run test`, `yarn run test:browser` (chromium and firefox), `yarn
run lint` and `yarn run typecheck` pass. The webkit browser run fails
one focus test in this local environment, identically on unmodified
`main`, so it is unrelated to this change.

---------

Co-authored-by: dermotduffy <dermot.duffy@gmail.com>

2026-08-30 14:04:40 -07:00

Matthijsanddermotduffy

fc7e09952f

fix: vertically center icons within icon buttons (#2734 )

Menu icons sit visibly high inside their round buttons in the iOS
companion app, and one pixel high everywhere else. The card's icon
wrapper (`advanced-camera-card-icon`) is slotted into `ha-icon-button`,
whose label renders slotted content inside a plain `<span>`. The wrapper
is an `inline-block`, so it rides the text baseline and leaves the
font's descender space underneath it: the span grows taller than the
icon (measured: 24.5px around a 22.5px icon under Roboto), the button's
flex layout centers the *span*, and the icon lands high by half the
descent.

That descent is a property of the active font, which is why the offset
differs per platform: about 1px under Roboto, and about 2px when the
font stack resolves to a system font, as on iOS, where it is clearly
visible inside the round menu button background. Slotted Home Assistant
icons do not show this because they are laid out block-level via
`--ha-icon-display`, which the card already sets; the card's own wrapper
element reintroduces the inline-block one level up.

**Change:** lay the wrapper out block-level wherever it is slotted into
`ha-icon-button` (`button.scss`, which also covers the submenu and
next/previous controls). Block layout has no baseline, so the label span
shrinks to exactly the icon and the icon centers.

**Verification:**

- The structure (flex button, label span, slotted icon) rebuilt
standalone in Playwright Chromium and WebKit: with an inline-block icon
the offset is 1px under Roboto and 1.75 to 2px under system fonts, in
both engines; with a block icon it is 0.0px in every engine, font, and
button size tried.
- Measured on a live HA 2026.8.3 dashboard (45px menu buttons): before,
every menu icon center sat 1px above its button center; after, 0.0px for
both a standard menu button and a conditional
`advanced-camera-card-menu-icon` element.
- `yarn run test`, `yarn run test:browser` (chromium), `yarn run lint`,
`yarn run typecheck` pass.

---------

Co-authored-by: dermotduffy <dermot.duffy@gmail.com>

2026-08-30 12:11:10 -07:00