Bug 105462 - In GNOME 3, GTK3 dialog boxes can't be moved to show the text behind
Summary: In GNOME 3, GTK3 dialog boxes can't be moved to show the text behind
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected) release
Hardware: All Linux (All)
: medium enhancement
Assignee: Not Assigned
: 113522 114267 135598 (view as bug list)
Depends on:
Blocks: GTK3
  Show dependency treegraph
Reported: 2017-01-21 09:03 UTC by Luke
Modified: 2020-12-21 11:17 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Example of a dialog box blocking information (476.38 KB, image/png)
2017-01-22 04:40 UTC, Luke
With GTK2 backend, I can move the dialog out of the way (754.44 KB, image/png)
2017-01-22 04:45 UTC, Luke

Note You need to log in before you can comment on or make changes to this bug.
Description Luke 2017-01-21 09:03:07 UTC
It's often useful to view the text behind the dialog box by moving the dialog box out of the way. Other VCL toolkits allow this such as Windows and SAL_USE_VCLPLUGIN=gtk. Other GTK3 apps allow child dialog boxes to be moved. 

I use resizing as a workaround, but it's a bit of a hacking solution as it causes the whole main window to restore and limit your ability to resize.
Comment 1 Xisco Faulí 2017-01-21 15:25:45 UTC
is it happening with an specific dialog? or with all of them?


Build ID: d3ff66999d924e832f8219c65ced0526f1a67f82
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

I can move the dialogs...
Comment 2 Luke 2017-01-21 17:26:58 UTC
Most of them. Make sure you're using the gtk3 backend. Steps to reproduce.

1. SAL_USE_VCLPLUGIN=gtk3 ./libreoffice

2. New text document

3. right click -> paragraph

I could reproduce this problem with Fedora 25 with both wayland and xorg.
Comment 3 Luke 2017-01-22 04:40:24 UTC
Created attachment 130602 [details]
Example of a dialog box blocking information

Are my instructions really that hard to follow? Maybe pictures will help.
Comment 4 Luke 2017-01-22 04:45:04 UTC
Created attachment 130603 [details]
With GTK2 backend, I can move the dialog out of the way

With Windows, gtk2, and other native gtk3 applications such as Gnumeric and gedit can all move dialogs. 

Not being able to see the content that your dialogs are supposed to be editing is a major real-world usability issue for an office suite.
Comment 5 Luke 2017-01-23 19:00:29 UTC
This seems to be a GNOME specific bug. I could reproduce this on:
* Fedora 25 with GNOME
* Arch with GNOME. 

I could NOT reproduce this with: 
* Arch + KDE 
* Ubuntu Unity
Comment 6 Hussam Al-Tayeb 2017-01-24 08:35:38 UTC
It is using a modal dialog under gtk3.
Comment 7 Caolán McNamara 2017-01-25 20:20:29 UTC
This is not a bug, or at least, not our bug and not behavior specific to LibreOffice, you'll see the same in other gtk3 applications. Its "attached modal dialogs"

You can disable it for the desktop with gnome-tweak-tool and the "windows" tab and toggle off "attached modal dialog" which is on by default on gnome 3.
Comment 8 Luke 2017-01-26 09:02:12 UTC
Many native gtk3 applications such as gnumeric and gedit do not have this issue. Is it something that can be controlled on the application side?
Comment 9 Maxim Monastirsky 2017-10-30 19:28:00 UTC
*** Bug 113522 has been marked as a duplicate of this bug. ***
Comment 10 Clément L. 2017-11-02 23:09:58 UTC
Filed https://bugzilla.gnome.org/show_bug.cgi?id=789838 as folowu-up bug.
Comment 11 Maxim Monastirsky 2017-12-16 21:44:13 UTC
*** Bug 114267 has been marked as a duplicate of this bug. ***
Comment 12 Maxim Monastirsky 2020-08-10 12:45:10 UTC
*** Bug 135598 has been marked as a duplicate of this bug. ***
Comment 13 Kevin Suo 2020-12-21 08:23:22 UTC
Caolán: Sorry, but I think we should do something to improve this. Dialogs should be set "modal" only if there is a reason to freeze other windows (e.g., waiting for user input while we do not want the user to change the content in other windows). If there is no such a reason, we should not set it as "modal".

At least I have found that using Glade, there is a option "modal" to the dialog, and I have successfully set the "Format Cells" dialog as non-modal. Will submit a patch on gerrit for this dialog then. For instance:

In sc/uiconfig/scalc/ui/formatcellsdialog.ui, if I change the following:
<property name="modal">True</property>

<property name="modal">False</property>

then this dialog is movable again.
Comment 14 Kevin Suo 2020-12-21 10:04:05 UTC
Have done a few of them:

Caolán: would you please review and provide your thoughts, before more dialogs to be set this way?
Comment 15 Caolán McNamara 2020-12-21 11:06:02 UTC
You can't just flip that bit safely. If its modal you can't interact with the window underneath the dialog, if its not modal then you can and generally the application isn't prepared to handle that and its possible to change the document that the dialog will operate on in ways they don't expect. Or the user can spawn new dialogs and other interactions which will crash the app.

Its an unfortunate side-effect of being modal that gnome will attach the dialog to its parent in a way that its not movable. There is a global option, available under "Windows" in gnome-tweaks, to turn off Attach Modal Dialogs. There isn't an intrinsic need for modal dialogs to be not movable, but a gnome-level default feature that is making that happen.
Comment 16 Kevin Suo 2020-12-21 11:17:49 UTC
(In reply to Caolán McNamara from comment #15)
Understood. I will abandon those patches then. Thank you Caolan.