wispd currently opens notification popups with an estimated height, then renders them, queries widget bounds, and resizes/reflows the popup stack based on the measured result.
This was originally implemented as a pragmatic workaround because popup height depends on dynamic content (formatted text, wrapping, icons, action rows, progress bar), and it was easier to render first and
inspect the result than to build a reliable pre-layout sizing model up front.
In practice, this has turned out to be fragile and likely causes interaction/layout issues.
Current behavior
- popup height is initially guessed via estimate_popup_height()
- the UI then measures rendered bounds (FindWidgetBounds / MeasuredPopupHeight)
- if the measured height differs, the popup is resized and the stack is relaid out
Problems observed
- click-to-dismiss hit area can feel “off” compared to the visible popup
- popup geometry can shift after first render
- hidden notifications used to trigger repeated no-bounds measurement retries
- layout behavior is harder to reason about because there are effectively two sizing systems:
- estimated layout
- render-time measured layout
Desired direction
Remove the render-time measurement pipeline and make popup sizing deterministic before opening the window.
Suggested implementation
- remove:
- FindWidgetBounds
- measure_notification_height_task
- MeasuredPopupHeight
- pending_measure
- render-time relayout driven by measured bounds
- make estimate_popup_height() (or a replacement helper) the single source of truth for popup height
- keep render-time layout rules aligned with the same sizing assumptions
- prefer stable geometry over pixel-perfect post-render correction
Acceptance criteria
- popup windows do not resize/reflow after first render
- click-to-dismiss hit area matches visible popup geometry consistently
- no repeated “popup height measurement returned no bounds” warnings
- stack layout remains stable when notifications are added, replaced, promoted, or dismissed
Notes
A bounded/fixed-height layout would also be acceptable if that ends up being simpler and more reliable than fully dynamic content-based sizing.
wispd currently opens notification popups with an estimated height, then renders them, queries widget bounds, and resizes/reflows the popup stack based on the measured result.
This was originally implemented as a pragmatic workaround because popup height depends on dynamic content (formatted text, wrapping, icons, action rows, progress bar), and it was easier to render first and
inspect the result than to build a reliable pre-layout sizing model up front.
In practice, this has turned out to be fragile and likely causes interaction/layout issues.
Current behavior
Problems observed
Desired direction
Remove the render-time measurement pipeline and make popup sizing deterministic before opening the window.
Suggested implementation
Acceptance criteria
Notes
A bounded/fixed-height layout would also be acceptable if that ends up being simpler and more reliable than fully dynamic content-based sizing.