Skip to content

[Feature] Overlay visible in fullscreen apps and click-through for transparent regions #472

@senamakel

Description

@senamakel

Summary

Improve the desktop overlay so it remains usable when other apps are in exclusive fullscreen, and so transparent parts of the overlay do not steal mouse clicks from underlying windows. Users should see the overlay when they expect it, and only real overlay UI should receive pointer input.

Problem

Fullscreen visibility: Today the overlay can be hard or impossible to see when a foreground app is running in fullscreen (or space) modes where a normal floating window does not appear above the fullscreen surface. That breaks flows where the overlay is meant to stay accessible (e.g. autocomplete/orb) while the user works fullscreen.

Click blocking: The overlay window uses a transparent background so only the orb and related UI are visually opaque. On some platforms the window still participates in hit testing as a full rectangle, so clicks in empty space are swallowed and do not reach the app underneath. That makes the overlay feel broken when users try to interact with the fullscreen app behind it.

Who it hurts: Anyone using the overlay while another app is fullscreen, and anyone who expects to click through transparent areas to the underlying UI.

Constraints: Behavior differs by OS (macOS NSWindow / levels / collection behavior; Windows layered windows; Linux compositors). Changes should stay within Tauri/desktop shell responsibilities where possible, with platform-specific native tweaks when required. Performance and security of the overlay surface should not regress.

Solution (optional)

  • Fullscreen: Audit and extend per-platform window configuration (e.g. macOS collection behavior and window level; Windows layered windows / topmost / DPI; Linux compositor-friendly flags) so the overlay can appear in the same visual context as fullscreen apps where the OS allows it. Document any OS limitations (e.g. true exclusive fullscreen may not allow overlays on some setups).

  • Click-through: Use platform APIs so the window (or webview) ignores mouse events in fully transparent pixels, or set ignoresMouseEvents / equivalent for non-interactive regions while keeping hit testing on visible controls (orb, bubbles). May require native code in the Tauri shell or coordinated CSS/pointer-events only where it does not break WebView behavior.

  • Scope: Likely app/src-tauri plus overlay WebView (app/src/overlay/) as needed; verify Rust-side overlay setup (e.g. configure_overlay_window_*).

Acceptance criteria

  • Fullscreen — With a typical fullscreen app focused (test on macOS at minimum; Windows/Linux if in scope), the overlay is visible and positioned as designed, or documented limitations are explicit in UX/docs.
  • Click-through — Clicks on transparent overlay areas pass through to the application behind; interactive overlay elements still receive clicks and drags as today.
  • Regression — No loss of always-on-top / multi-workspace behavior for the overlay where already implemented; manual or automated checks noted for overlay window setup.
  • Docs — Short note in developer or user-facing docs if platform-specific caveats apply.

Related

  • Overlay window configuration in Tauri (configure_overlay_window_macos, overlay Webview label overlay).

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions