Description of problem: closing some MCC applications with "x" does not close the window. If "x" is pressed 2x, MCC will exit. "Cancel" will close the window.
Particularly noticable in "Local disks" and "Network sharing"
Version-Release number of selected component (if applicable):
DATE.txt: Tue Feb 28 22:03:40 CET 2017
How reproducible:every time
Steps to Reproduce:
1.install Cinnamon DE only from above .iso (USB)
2.invoke MCC from Mageia Welcome
3.invoke an application from "Network sharing" or "Local disks"
4.attempt to close application with "x" (top right)
5.attempt again with "x", MCC will exit
also valid for upgrade Mga 5.1 x86_64 using Classical Install.iso
also valid for Gnome from
DATE.txt: Wed Mar 1 11:09:58 CET 2017
Created attachment 9089 [details]
Gnome i586 report.bug.xz
share your hard disk partitions,
access WebDAV shared drives and directories
access NFS shared drives and directories
access Windows (SMB) shared drives and directories
DATE.txt: Fri Apr 7 23:11:51 CEST 2017
Can you reproduce the issue only when MCC is called from the Mageia Welcome page, or also when called later, e.g. from the "start menu"? If this is only a problem when called from the Mageia Welcome page, I wouldn't qualify this bug as a release blocker.
I can reproduce the issue on Plasma, and also without starting from MageiaWelcome (just starting "mcc" from the terminal).
It does not affect all embedded applications, but at least those:
- Network Sharing: Accessing Windows (SMB) shared drives and directories
- Network Sharing: Accessing NFS shared drives and directories
- Network Sharing: Accessing WebDav shared drives and directories
- Local disks: Manage disk partitions
- Local disks: CD/DVD burner
- Local disks: Share your hard disk partitions
All other applications seem to work fine as far as this glitch is concerned.
@ Thierry, any idea about what could be special in the embedded of those Network sharing and Local disks applications that could cause the bug?
Not a release blocker, it's only a minor inconvenience and can be fixed by an update after the release. It would of course be very positive to have this fixed before the release :)
It seems to all be diskdrake with different options
It seems to have:
*** Bug 20829 has been marked as a duplicate of this bug. ***
This bug was introduced when we added the wrapper round diskdrake to use udisks-inhibit. In both /usr/libexec/drakdisk and in /usr/lib/udisks2/udisks2-inhibit we need to use 'exec' to chain the commands.
But using 'exec' in /usr/lib/udisks2/udisks2-inhibit stops it restoring the udev rules after diskdrake exits, so that's not a solution.