Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug] Weird Menu behaviour with custom titlebar #12074

Open
ScepticDope opened this issue Dec 29, 2024 · 0 comments
Open

[bug] Weird Menu behaviour with custom titlebar #12074

ScepticDope opened this issue Dec 29, 2024 · 0 comments
Labels
status: needs triage This issue needs to triage, applied to new issues type: bug

Comments

@ScepticDope
Copy link

Describe the bug

So there is some buggy behaviour going on with my menu. My app can switch from a custom titlebar to no custom titlebar using appWindow.setDecorations() while running.

The menu stays in place, but you can't click on it, and only if you use Alt to access it can you use the mouse on it as normal. It also looks off. I tried to offset my html and even not capture any pointer events, but it seems the menu is completely outside the scope of the dom and actually sits behind the window rendering the webview until it becomes active using alt. See this gif:

capture

As you can see there is also weird rendering on resize its hidden then when it gets out of focus or you use Alt its back again.

Also, the menu is transparent, my window has "transparent": true, which looks bad. The menu should not be transparent or have an option in how much its transparent. If transparent is false, this buggy menu behaviour is still there, this is just a side note.

Reproduction

Run on Windows 10. Add a menu and a custom titlebar. See the chaos.

Expected behavior

I'd expect that on Windows, if there is a menu, it will claim space below your custom title bar and just sit there nicely and work as intended with the mouse, sitting above the whole web view. For MacOS and Linux, the menu bar can stay at the operating system level in its default location, which works fine at the moment.

A temporary solution would be to simply disable the menu if Decorations is set to false specifically for Windows. But of course, eventually you want your sweet cross-platform menu to work on all platforms and not have to create a custom HTML menu just for fucking Windows...

Full tauri info output

[✔] Environment
    - OS: Windows 10.0.19045 x86_64 (X64)
    ✔ WebView2: 131.0.2903.112
    ✔ MSVC: Visual Studio Build Tools 2022
    ✔ rustc: 1.83.0 (90b35a623 2024-11-26)
    ✔ cargo: 1.83.0 (5ffbef321 2024-10-29)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (environment override by RUSTUP_TOOLCHAIN)

[-] Packages
    - tauri 🦀: 2.1.1
    - tauri-build 🦀: 2.0.3
    - wry 🦀: 0.47.2
    - tao 🦀: 0.30.8
    - tauri-cli 🦀: 2.1.0

[-] Plugins

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../src

Stack trace

No response

Additional context

No response

@ScepticDope ScepticDope added status: needs triage This issue needs to triage, applied to new issues type: bug labels Dec 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: needs triage This issue needs to triage, applied to new issues type: bug
Projects
None yet
Development

No branches or pull requests

1 participant