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] Window loses focus when creating another window with focus: false, possible deadlock when re-focusing main window manually #5120

Closed
andrepav1 opened this issue Sep 1, 2022 · 4 comments
Labels
status: needs triage This issue needs to triage, applied to new issues type: bug

Comments

@andrepav1
Copy link

Describe the bug

We want to be able to create a second window on the onFocus event in a React input component, while keeping the same input focused.

Seems like the intended way of doing this is setting the focus property to false, but this doesn't seem to do the trick.

We also tried using setFocus() inside the "tauri://created" listener to re-focus the primary window manually but this seems to cause a deadlock, as the cursor in the input is blinking but the first button pressed does not register.

Reproduction

  1. Go to repo https://github.com/Andrepav1/tauri-multi-window
  2. Run yarn && yarn start
  3. Run tauri dev
  4. Focus input component and wait window creation
  5. Press any key

Expected behavior

Create the window, while keeping the focus on the input component.

Platform and versions

Environment
› OS: Windows 10.0.19044 X64
› Webview2: 104.0.1293.70
› MSVC:
- Visual Studio Build Tools 2022
› Node.js: 16.15.0
› npm: 8.5.5
› pnpm: 7.1.0
› yarn: 1.22.15
› rustup: 1.25.1
› rustc: 1.62.1
› cargo: 1.62.1
› Rust toolchain: stable-x86_64-pc-windows-msvc

Packages
› @tauri-apps/cli [NPM]: 1.0.5
› @tauri-apps/api [NPM]: 1.0.2
› tauri [RUST]: 1.0.5,
› tauri-build [RUST]: 1.0.4,
› tao [RUST]: 0.12.2,
› wry [RUST]: 0.19.0,

App
› build-type: bundle
› CSP: default-src blob: data: filesystem: ws: http: https: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'
› distDir: ../build
› devPath: http://localhost:3000/
› framework: React

App directory structure
├─ .git
├─ node_modules
├─ public
├─ src
└─ src-tauri

Stack trace

no stack trace

Additional context

No response

@andrepav1 andrepav1 added status: needs triage This issue needs to triage, applied to new issues type: bug labels Sep 1, 2022
@dannyvaughton
Copy link

I've been seeing this issue too.

Creating a new window with focus: false, whether visible or not, will still cause the window to lose focus. I've also tried running the setFocus manually afterward, but it does not seem to bring it back into focus. I believe it's because Tauri thinks the window is still in focus, when it's not. I'm assuming this because once you manually blur the window, the setFocus then works.

@amrbashir
Copy link
Member

the focus was introduced briefly but has been removed from tao. I think we just forgot to remove it from tauri too. cc @lucasfernog

@lucasfernog
Copy link
Member

You're right @amrbashir I guess we could change it to use set_focus now.

@amrbashir
Copy link
Member

we can't, set_focus can only grab focus not lose it. this has to be done when first creating the window at least on Windows. I plan to add that back once we migrate to winit but for now we need to remove this option.

amrbashir added a commit to tauri-apps/tao that referenced this issue Sep 30, 2022
amrbashir added a commit to tauri-apps/tao that referenced this issue Oct 3, 2022
* feat: add `WindowBuilder::with_focused`

ref: tauri-apps/tauri#5120

* fix linux build

* macos orderfront only

* restore accept-focus

* fix linux impl

* remove set_transient_for call

* Update src/window.rs

* Update src/window.rs

* Update src/platform_impl/linux/window.rs

* fmt

* import parent

Co-authored-by: Lucas Nogueira <lucas@tauri.studio>
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

4 participants