starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

qBt master goes to tray when exited from WebUI #13820

New issue

Closed

opened 2026-02-22 00:22:19 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-22 00:22:19 -05:00

Owner

Originally created by @ghost on GitHub (Sep 12, 2022).

Originally assigned to: @glassez on GitHub.

qBittorrent & operating system versions

qBittorrent: 4.5.0alpha1 x64
Operating system: Windows 10 Pro 21H2 x64
Qt: 6.3.0
libtorrent-rasterbar: 2.0.7.0

What is the problem?

It goes to tray instead of shutting down and quitting when exited from the WebUI.

Steps to reproduce

Exit qBit from WebUI
See qBt go to tray instead of quitting

Additional context

No response

Log(s) & preferences file(s)

Log doesn't say anything related to it.

Originally created by @ghost on GitHub (Sep 12, 2022). Originally assigned to: @glassez on GitHub. ### qBittorrent & operating system versions qBittorrent: 4.5.0alpha1 x64 Operating system: Windows 10 Pro 21H2 x64 Qt: 6.3.0 libtorrent-rasterbar: 2.0.7.0 ### What is the problem? It goes to tray instead of shutting down and quitting when exited from the WebUI. ### Steps to reproduce 1. Exit qBit from WebUI 2. See qBt go to tray instead of quitting ### Additional context _No response_ ### Log(s) & preferences file(s) Log doesn't say anything related to it.

deekerman

2026-02-22 00:22:19 -05:00

closed this issue
added the
Confirmed bug

WebAPI
labels

deekerman commented

2026-02-22 00:22:29 -05:00

Author

Owner

@Chocobo1 commented on GitHub (Sep 12, 2022):

I confirm.

@glassez
Seems like a regression related to your application interface refactoring!?

@Chocobo1 commented on GitHub (Sep 12, 2022): I confirm. @glassez Seems like a regression related to your application interface refactoring!?

deekerman commented

2026-02-22 00:22:31 -05:00

Author

Owner

@glassez commented on GitHub (Sep 13, 2022):

@glassez
Seems like a regression related to your application interface refactoring!?

What do you mean exactly?

It goes to tray instead of shutting down and quitting when exited from the WebUI.

Confirmed.
But if window is already hidden in tray qBittorrent really exits. Could you check it?
Also could you confirm that there is no such problem in qBittorrent 4.4.x with the same Qt?

@glassez commented on GitHub (Sep 13, 2022): > @glassez > Seems like a regression related to your application interface refactoring!? What do you mean exactly? > It goes to tray instead of shutting down and quitting when exited from the WebUI. Confirmed. But if window is already hidden in tray qBittorrent really exits. Could you check it? Also could you confirm that there is no such problem in qBittorrent 4.4.x with the same Qt?

deekerman commented

2026-02-22 00:22:31 -05:00

Author

Owner

@ghost commented on GitHub (Sep 13, 2022):

Seems like it happens with qt6 only in 4.4.x.

@ghost commented on GitHub (Sep 13, 2022): Seems like it happens with qt6 only in 4.4.x.

deekerman commented

2026-02-22 00:22:31 -05:00

Author

Owner

@glassez commented on GitHub (Sep 13, 2022):

Seems like it happens with qt6 only in 4.4.x.

And I suppose in master too (Qt6 only).

@glassez commented on GitHub (Sep 13, 2022): > Seems like it happens with qt6 only in 4.4.x. And I suppose in master too (Qt6 only).

deekerman commented

2026-02-22 00:22:31 -05:00

Author

Owner

@glassez commented on GitHub (Sep 14, 2022):

@glassez
Seems like a regression related to your application interface refactoring!?

There is no regression related to my refactoring.
There is a difference between Qt5 and Qt6 of how QCoreApplication::quit() behaves.
Qt5:

Tells the application to exit with return code 0 (success).
Equivalent to calling QCoreApplication::exit(0).

Qt6:

Asks the application to quit.
The request may be ignored if the application prevents the quit,
for example if one of its windows can't be closed. The application
can affect this by handling the QEvent::Quit event on the application
level, or QEvent::Close events for the individual windows.
If the quit is not interrupted the application will exit with return
code 0 (success).

So in Qt6 we go into Close event handler that behaves the same way as if the user clicked the window close button.

@glassez commented on GitHub (Sep 14, 2022): > @glassez > Seems like a regression related to your application interface refactoring!? There is no regression related to my refactoring. There is a difference between Qt5 and Qt6 of how `QCoreApplication::quit()` behaves. Qt5: >Tells the application to exit with return code 0 (success). Equivalent to calling `QCoreApplication::exit(0)`. Qt6: >Asks the application to quit. The request may be ignored if the application prevents the quit, for example if one of its windows can't be closed. The application can affect this by handling the `QEvent::Quit` event on the application level, or `QEvent::Close` events for the individual windows. If the quit is not interrupted the application will exit with return code 0 (success). So in Qt6 we go into Close event handler that behaves the same way as if the user clicked the window close button.

deekerman commented

2026-02-22 00:22:31 -05:00

Author

Owner

@Chocobo1 commented on GitHub (Sep 14, 2022):

There is no regression related to my refactoring.

I erroneously mixed up with something else, excuse me.

There is a difference between Qt5 and Qt6 of how QCoreApplication::quit() behaves.

I see, I'll take a closer look to it.

@Chocobo1 commented on GitHub (Sep 14, 2022): >There is no regression related to my refactoring. I erroneously mixed up with something else, excuse me. >There is a difference between Qt5 and Qt6 of how QCoreApplication::quit() behaves. I see, I'll take a closer look to it.

deekerman commented

2026-02-22 00:22:31 -05:00

Author

Owner

@Chocobo1 commented on GitHub (Sep 14, 2022):

Please test PR #17720.

@Chocobo1 commented on GitHub (Sep 14, 2022): Please test PR #17720.