| Summary: | Save dialog can appear outside the viewport with multi-page desktops | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Vincent Lefevre <vincent-docf> |
| Component: | UI | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | major | CC: | miniopl, rene |
| Priority: | medium | ||
| Version: | 3.6.0.0.alpha1 | ||
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| See Also: | http://bugs.debian.org/728106 | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
|
Description
Vincent Lefevre
2013-10-28 15:51:50 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. (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? 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. (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. 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 According to the fvwm man page, fvwm is EWMH compliant (see the "EXTENDED WINDOW MANAGER HINTS" section). ** 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 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. |