Description of problem: Libreport is used by python-meh for graphical crash reporting in the Anaconda installation environment and by Initial Setup after the installation. This graphical environment is very simple and does not support switching between windows. This has the side effect that if the user click outside of the libreport window while filling in bugrpoert details the window (and any user input inside it) will be lost, as it gets hidden behind the Anaconda window without any means of getting it back. This can be prevented by libreport providing an option to show its window in a keep-above mode, so that it can't loose focus, which in turn prevents the data loss due to the hidden window. How reproducible: always Steps to Reproduce: 1. start installation in the graphical mode 2. trigger an exception[0] 3. select the option to report a bug to bugzilla 4. once the libreport window shows up click outside of it Actual results: The window vanishes (it gets hidden behind the Anaconda window) and there is no way to get it back. Expected results: Clicking outside of the window does nothing, the libreport window keeps focus until terminated. Additional info: The Connection Editor utility, which is also used in a similar way in Anaconda and Initial Setup, has recently implemented this functionality to prevent similar issues with loosing user entered data. This has been implemented by adding a --keep-above flag top the CLI API Anaconda uses the launch Connection Editor, which internally triggers the gtk_window_set_keep_above[0] call. As libreport is used via the Python API by python-meh in the Anaconda/IS environment the API should proabably be extended so that the keep-above mode can be requested for the libreport window. [0] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_bugzilla [1] https://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-set-keep-above
*** Bug 1271625 has been marked as a duplicate of this bug. ***
Martin, can't you use wmctrl from anaconda environment to set correct window flags on arbitrary windows, without the need for each to implement this?
(In reply to Kamil Páral from comment #2) > Martin, can't you use wmctrl from anaconda environment to set correct window > flags on arbitrary windows, without the need for each to implement this? We have investigated this with vtrefny and it looks like wmctrl won't do: * it seems to only work with Metacity - we currently do use Metacity on our installation images, but live images can & do use different WMs - Initial Setup runs after installation and often also runs under different WM than Metacity * it only works with X - this could be an issue when Wayland is the default * upstream looks pretty dead (latest version is from 10th October 2005) * the window is spawned from an imported module, not by calling a binary so there might be issues to differentiate the libreport window from the Anaconda ones On the other hand the suggested solution (calling gtk_window_set_keep_above from libreport) is already known to work fine all the environments where Anaconda and Initial Setup is expected to be running. It is also a part of the GTK public API, so we can expect it should work in the same way also on Wayland.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.