[bug] appWindow.unminize() does not respect maximized window

[elibroftw]

Describe the bug

When using unminize on a maximized window that is minimized, the window is restore to the maximized size but is not actually maximized as indicated by the square icon in the top right of the window on Windows.

Reproduction

1. Run any app in development
2. Open devtools
3. Maximize app
4. Minimize app
5. in devtools use window.__TAURI__.unminimize()

Expected behavior

The window should restore as maximized not resized to the max size

Platform and versions

$ tauri info

Environment
  › OS: Windows 10.0.19044 X64
  › Webview2: 107.0.1418.35
  › MSVC: 
      - Visual Studio Community 2022
  › Node.js: 17.3.1
  › npm: 8.3.0
  › pnpm: Not installed!
  › yarn: 1.22.11       
  › rustup: 1.24.3
  › rustc: 1.61.0
  › cargo: 1.61.0
  › Rust toolchain: stable-x86_64-pc-windows-msvc 

Packages
  › @tauri-apps/cli [NPM]: 1.2.0
  › @tauri-apps/api [NPM]: 1.2.0
  › tauri [RUST]: 1.2.0,
  › tauri-build [RUST]: 1.2.0,
  › tao [RUST]: 0.15.1,
  › wry [RUST]: 0.22.0,

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

App directory structure
  ├─ .git
  ├─ .github
  ├─ .idea
  ├─ assets
  ├─ build
  ├─ node_modules
  ├─ public
  ├─ src
  ├─ src-tauri
  └─ utils
Done in 8.10s.

Stack trace

No response

Additional context

isMaximized returns false if a maximized window is minimzed :(

[elibroftw]

https://devblogs.microsoft.com/oldnewthing/20040707-00/?p=38523

If you have a minimized window and want to know where it will go when you restore it, the GetWindowPlacement function will tell you. In particular, the rcNormalPosition tells you where the window would go if it were restored (as opposed to minimized or maximized). One perhaps-non-obvious flag is WPF_RESTORETOMAXIMIZED. This flag indicates that the window is currently minimized, but if the user selects “Restore”, it will restore to its maximized instead of restored state. (This may seem strange, but you see it every day without even realizing. Take a window and maximize it. Now minimize it. Now click the taskbar button to re-open the window. Notice that it returns to its maximized state, not to its restored state. Imagine how frustrated you would be if it returned to its restored state instead. You’d have to keep re-maximizing the window.) The GetWindowPlacement and SetWindowPlacement functions are typically used by programs that wish to save/restore window positioning information across runs.

[elibroftw]

Also @amrbashir ,

You should also be aware that the coordinate system for window placement is not screen coordinates, but rather workspace coordinates. The consequence of getting this wrong is that your window creeps up (or to the left) over time, eventually getting itself stuck underneath the taskbar.

This may be useful for the tauri-plugin-window-state

https://stackoverflow.com/questions/29747238/how-to-convert-workspace-coordinates-to-screen-coordinates

[amrbashir]

finally found the bug, WS_MAXIMIZE was not set when restoring the window from minimize state, could you give #638 a try?

[elibroftw]

Sorry for the late reply, I spent yesterday debugging another project of mine. I put this in my Cargo.toml just now and it did not fix the issue. Am I doing this correctly?

tao = { git = "https://github.com/tauri-apps/tao", branch = "dev" }

index.html

appWindow.unminimize().then(() => appWindow.setFocus(true));

[amrbashir]

did you run cargo update inside src-tauri?

[elibroftw]

Yeah I did no difference.

I don't think I added it to cargo properly though.

[amrbashir]

try

[patch.crates-io]
tao = { git = "https://github.com/tauri-apps/tao", branch = "dev" }

[elibroftw]

Yeah that's what I'm trying now

[elibroftw]

It works! 🎉

[elibroftw]

Can we expect this change to come into Tauri in like a month?

[amrbashir]

roughly yeah