Bug 70963 - Save dialog can appear outside the viewport with multi-page desktops
Summary: Save dialog can appear outside the viewport with multi-page desktops
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.6.0.0.alpha1
Hardware: Other Linux (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-28 15:51 UTC by Vincent Lefevre
Modified: 2015-06-09 17:45 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Lefevre 2013-10-28 15:51:50 UTC
Under some conditions described below, the Save dialog can appear outside the viewport. In some cases, the unchanged data cannot be saved and are lost (even after LibreOffice's recovery feature). I first reported this bug on the Debian BTS:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728106

To reproduce the bug, you need the Fvwm window manager (or any window manager that works in a similar way to implement multi-page desktops). Use the following desktop config:

  DeskTopSize 3x2

(2x1 is sufficient, but the 3 pages positioned horizontally help to see what happens) and the FvwmPager module. Then do the following steps:

1. On Page 2, open a first file with "libreoffice file1.odt", and modify it (but do not save it).

2. On Page 3, open a second file with: "libreoffice file2.odt". So, one has:

  |  Page 1   |  Page 2   |  Page 3   |
  |           | file1.odt | file2.odt |
  |           |           |  VISIBLE  |

3. In the file2.odt window, type Ctrl-Q to quit.

LibreOffice switches to Page 2 (perhaps by raising or giving the focus to the file1.odt window), and the "Save" dialog appears on Page 1 instead of Page 2:

  |  Page 1   |  Page 2   |  Page 3   |
  |  "Save"   | file1.odt | file2.odt |
  |           |  VISIBLE  |           |

More precisely, FvwmDebug information shows that the X coordinate of the "Save" dialog is a large negative number, which corresponds to the left of the currently visible page. If file1.odt is on the leftmost page, the "Save" dialog doesn't appear at all, and the user can't do anything to save the file (which is what I initially reported on the Debian BTS, after finding information with FvwmDebug).

I think that the following happens when LibreOffice wants to display the "Save" dialog over the file1.odt window (after receiving the Ctrl-Q). I haven't looked at the sources, but this can explain what I could see above:

First, I don't know exactly how fvwm implements multi-page desktops, but I think it does that by translating the coordinates of the windows. That's why, for instance, a window can appear partly on two adjacent pages. So, when I move to the right page, the X coordinates of the windows on the left page become negative.

1. LibreOffice gets the coordinates of the file1.odt window (currently negative, as on Page 2, while Page 3 of the desktop is being displayed), with the goal to display the "Save" window above the file1.odt window.

2. LibreOffice makes fvwm switch to Page 2 (perhaps by raising or giving the focus to the file1.odt window). This makes fvwm translate the coordinates of all the windows at the same time.

3. LibreOffice opens the "Save" window, using the coordinates obtained in (1). But the problem is that these coordinates are not up-to-date!
Comment 1 Mirosław Zalewski 2013-10-28 16:45:22 UTC
Since you were really in hurry to report this here, let me ask you a question:
are you using GTK LibreOffice interface?
If so, can you switch to generic X11 interface (`export SAL_USE_VCLPLUGIN=gen && libreoffice`) and try to reproduce that bug? What are the results?

I could reproduce this issue on fvwm only (I tried KDE, JWM, Openbox and Fluxbox), which lean me towards closing this as NOTOURBUG.

But even on fvwm, I could reproduce it only on GTK interface (did not check KDE, though). GTK interface takes advantage of window manager tips described in EWMH. EWMH was introduced over decade ago, but fvwm is NOT EWMH-compliant (it supports only older ICCCM). So I am afraid that fvwm developers will find this not their bug, either (it's outcome of their design decisions).

Also, I could reproduce this issue on master snapshot ID 099198a4224778fe6e43f5dc13b5b9b1b4dc828c (roughly week before 3.6 branching), so I set version field accordingly.
Comment 2 Vincent Lefevre 2013-10-28 17:11:00 UTC
(In reply to comment #1)
> Since you were really in hurry to report this here, let me ask you a
> question:
> are you using GTK LibreOffice interface?

Yes (the main purpose is to get readable fonts).

> If so, can you switch to generic X11 interface (`export
> SAL_USE_VCLPLUGIN=gen && libreoffice`) and try to reproduce that bug? What
> are the results?

With SAL_USE_VCLPLUGIN=gen, after moving the file2.odt window the right desktop page to be under the same conditions, I cannot reproduce the bug: LibreOffice doesn't try to switch the desktop[*] after Ctrl-Q, and as a consequence, the "Save" dialog appears on the current desktop.

[*] Desktop switching might be a consequence of raise / set focus.

> I could reproduce this issue on fvwm only (I tried KDE, JWM, Openbox and
> Fluxbox), which lean me towards closing this as NOTOURBUG.

I don't think fvwm is doing anything wrong here, and you haven't proved that reproducing the bug on KDE, etc. is impossible. IMHO, LibreOffice does a wrong assumption about the window coordinates.

> But even on fvwm, I could reproduce it only on GTK interface (did not check
> KDE, though). GTK interface takes advantage of window manager tips described
> in EWMH. EWMH was introduced over decade ago, but fvwm is NOT EWMH-compliant
> (it supports only older ICCCM). So I am afraid that fvwm developers will
> find this not their bug, either (it's outcome of their design decisions).

Could you explain what EWMH feature would make the bug impossible to reproduce?

If this really comes from a lack of EWMH support (something that would make the client aware that the coordinates have changed?), how about an option to let the window manager determine where the "Save" dialog would appear, instead of forcing some fixed coordinates?
Comment 3 Mirosław Zalewski 2013-10-28 17:54:51 UTC
Please don't get me wrong. I am not claiming that this is not bug in LibreOffice. I just have large share of doubt about it and I think we should not waste developer's precious time until these doubt are dispelled. It's your job as bug reporter to convince developers to fix that particular issue (instead of one of 6000 reports we have open), so all burden of proof lies on you.

So far, this bug has been observed only on fvwm and only when LO GTK interface was used. Which is enough to ring a bell that it might not be LibreOffice bug at all.

LO GTK interface usage of EWMH and fvwm lack of support for that gives us good starting point for explaining possible failure here.

If you think that it indeed is bug in LibreOffice, please prove that. By, for example, providing steps on how to reproduce it on EWMH-compliant window manager, such as KDE's KWin. Or pointing out in LibreOffice source code where exactly it is wrong. Or, better yet, proposing patch that fixes this issue.
Comment 4 Vincent Lefevre 2013-10-28 18:35:46 UTC
(In reply to comment #3)
> LO GTK interface usage of EWMH and fvwm lack of support for that gives us
> good starting point for explaining possible failure here.

I'd like to look at this more closely, but could you tell me what EWMH feature allows the bug not to appear?

> If you think that it indeed is bug in LibreOffice, please prove that.

The end of my bug report gives some hints.

> By, for example, providing steps on how to reproduce it on EWMH-compliant
> window manager, such as KDE's KWin.

I'll try to do some tests, but if the implementation is different, this becomes pointless.

> Or pointing out in LibreOffice source code where exactly it is wrong.
> Or, better yet, proposing patch that fixes this issue.

I'll try to look at that when I have the time. Unfortunately the LibreOffice source is huge. If you can tell me which source file(s) can be concerned by the bug, this would help me (I suppose some file in a gtk directory, since gtk2 is used under Debian). Or if there is a way to get detailed debugging information.
Comment 5 QA Administrators 2014-05-17 00:34:06 UTC
Dear Bug Submitter,

Please read the entire message before proceeding.

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here: 
https://wiki.documentfoundation.org/QA/FDO/NEEDINFO

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.


Thank you for helping us make LibreOffice even better for everyone!


Warm Regards,
QA Team
Comment 6 Vincent Lefevre 2014-05-17 01:21:07 UTC
According to the fvwm man page, fvwm is EWMH compliant (see the "EXTENDED WINDOW MANAGER HINTS" section).
Comment 7 QA Administrators 2015-06-08 14:42:17 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

   Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.3 or later)
   https://www.libreoffice.org/download/

   If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
 
 If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

   Update the version field
   Reply via email (please reply directly on the bug tracker)
   Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)

http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug 
3. Leave a comment with your results;
4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 
4b. If the bug was not present in 3.3 - add "regression" to keyword


Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2015-06-08
Comment 8 Vincent Lefevre 2015-06-09 17:45:27 UTC
I've tested the libreoffice 1:4.4.4~rc1-1 Debian package, and the behavior is now OK for me. The "Save" dialog now appears over the LibreOffice window that has unsaved data, which is fine, even though it may be on a page that is not visible[*] (the reason may be that I had to disable the EWMHActivateWindowFunc Fvwm function because Firefox does too much focus stealing). So, resolving as WFM.

[*] With the previous behavior, the page wasn't necessarily visible either, but the major problems were:
1. The "Save" dialog could be on a page with no LibreOffice window. And worse:
2. The "Save" dialog could be on a page that didn't exist, so that the dialog couldn't be retrieved in any way.