Bug 97306 - All LibreOffice apps blocked when a save dialog is opened (Gtk)
Summary: All LibreOffice apps blocked when a save dialog is opened (Gtk)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.0.2.2 release
Hardware: All Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: gtk3-whipping-boy
  Show dependency tree / graph
 
Reported: 2016-01-21 21:50 UTC by rodhos92
Modified: 2024-03-21 12:34 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description rodhos92 2016-01-21 21:50:10 UTC 
When a save dialog is opened in Writer the Calc interface is blocked, I mean, is not responding to any interaction with the user. Also, the opposite is true: when a save dialog is opened in Calc, Writer is not responding. (They are related in some way since when Calc crash, Writer also chashes.)

Steps to reproduce:

1. Open a Writer and a Calc instance.
2. Open a save dialog by clicking in the "save as" button in Writer (or Calc).
3. Go to Calc (or Writer) and check if everything is working okey.

What do I expect: Calc is working fine after opening a save dialog in Writer.

What actually happens: Calc is not responding until I close the save dialog in Writer.
Comment 1 Buovjaga 2016-01-28 15:11:18 UTC 
Reproduced on Linux with gtk and gtk3.

With gtk3, the blocking is not as severe. I can use toolbar buttons.

Launching with
SAL_USE_VCLPLUGIN=gen libreoffice

..there is no problem.

Ubuntu 15.10 64-bit 
Version: 5.0.4.2
Build ID: 1:5.0.4~rc2-0ubuntu1~wily1
Locale: en-US (en_US.UTF-8)

Version: 5.2.0.0.alpha0+
Build ID: c43fdd74097cb12f69f86fd1217dd2f41ccae101
CPU Threads: 2; OS Version: Linux 4.2; UI Render: default; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF-dbg, Branch:master, Time: 2016-01-25_23:43:01
Locale: en-US (en_US.UTF-8)
Comment 2 QA Administrators 2017-03-06 13:42:01 UTC Comment hidden (obsolete)
Comment 3 rodhos92 2017-05-22 17:28:43 UTC 
The bug is still present in Ubuntu 16.10 and LibreOffice 5.3.3.2

Bug behavior changed:

1. It only happens when clicking "Save As" in toolbar button, not in window menu.

2. The the blocking is less severe.

3. When I click "Open" button in the other App both programs crashed.

4. When I click "Insert Chart" button in Calc "Save As" window closes.
Comment 4 Buovjaga 2017-05-23 17:01:24 UTC 
(In reply to rodhos92 from comment #3)
> 3. When I click "Open" button in the other App both programs crashed.

You click Open while having Save as dialog on the screen? Or just click Open anytime?
Comment 5 QA Administrators 2018-05-24 02:45:45 UTC Comment hidden (obsolete)
Comment 6 rodhos92 2018-05-25 08:23:31 UTC 
Details have changed again. Tested in Ubuntu 18.04 and LibreOffice 6.0.3.2

1. Click save as button in Calc

2. Click open button in Writer

3. Click cancel in Calc's save as prompt

No result. The buttons are blocked.
Comment 7 Caolán McNamara 2018-12-14 16:01:06 UTC 
" 1. Click save as button in Calc
  2. Click open button in Writer
  3. Click cancel in Calc's save as prompt
  No result. The buttons are blocked. "

Each file dialog runs its own event loop. The first dialog runs it on top of the main event loop, then the second file dialog runs its event loop on top of the first file dialog loop.

So the middle loop, that of the first file dialog, cannot exit until the top loop, that of the second file dialog, exits.

This should be typical of nearly all the modal dialogs we have, e.g. start in calc and use format->cells, then in writer use format->title page. Now it should not be possible to close the format cells until format title is closed first. And for the same loop within a loop reason.

We do have *some* asynchronous dialogs, e.g. start in writer, and format->page, then in calc, format cells. The writer format page is an async dialog, so the format cells is running its event loop on top of the main loop as normal, but the format page dialog does not have its own loop, so it can be closed while the next dialog is still running.

To get these file dialog async I guess we'd have to implement XAsynchronousExecutableDialog for them, and rejig the calling code to pass in a listener to handle the dialog final response. This is a fairly big chunk of work for a fairly small gain.

All that said, I don't think there is any gtk specific part to this (remaining at this point anyway) unless there's any evidence to the contrary I'm missing ?
Comment 8 QA Administrators 2021-10-19 03:42:03 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2023-10-20 03:15:25 UTC Comment hidden (spam)