Bug 49665 - Window placement can't be controlled - privacy issue
Summary: Window placement can't be controlled - privacy issue
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.5.2 release
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: User-Profile Privacy
  Show dependency treegraph
 
Reported: 2012-05-08 20:00 UTC by mcq_public
Modified: 2022-05-21 03:39 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Screencaps showing this behavior (975.90 KB, image/png)
2012-08-15 00:27 UTC, JP
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mcq_public 2012-05-08 20:00:29 UTC
Problem description: 
Libreoffice windows open in unpredictable positions and, on multi-display systems, on unpredictable displays. Using compiz configuration to force placement does not work - Libreoffice overrides fixed placement settings of compiz. When libreoffice is FIRST started, it complies with the compiz settings (good). If all windows are closed a document always opens in the position of the main libreoffice window (good). If a document is already open any subsequent document, regardless of component (writer, calc, etc) opens on another output or a different position to that specified by the user.

Steps to reproduce:
1. Start libreoffice on a system with two or more displays
2. Open a document
3. Open a second document and note which display it opens on
4. Try to create compiz controls to force libreoffice documents to open at the pointer position, or some other window placement rule.
5. Observe that libreoffice ignores the compiz rule and opens with the same pattern as before.

Current behavior:
As described above.

Expected behavior:
My preference is for new documents to always open on the same output. Regardless of whether this is Libreoffice default behaviour, I expect libreoffice to follow the rules I specify to compiz.

Platform (if different from the browser): 
Ubuntu 12.04 and Ubuntu 11.04.
              
Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0

Why this is important:
I work in a health setting with a second display that is viewed by clients, primary display visible only to me. The current behaviour means I CANNOT open a second document and be certain it will display on my screen - confidential information can be displayed to a client and I have NO WAY of preventing this, other than to close all other documents first.
Comment 1 JP 2012-08-15 00:27:02 UTC
Created attachment 65575 [details]
Screencaps showing this behavior
Comment 2 JP 2012-08-15 00:28:37 UTC
This behavior is still present in v3.6.0.4.

Assuming I'm commenting on the same thing, there seem to be two issues:
* LibreOffice inconsistantly changes both the X window name and class properties, making it difficult/impossible to globally match LO windows.
* LibreOffice seems to deliberately ignores matching rules...under some circumstances.


If you'll have a look at the uploaded attachment, you'll see three screencaps of a 4-viewport session with transparent backgrounds - that Grand Canyon image is the skydome.
My Compiz rules specify that any windows with
  class="LibreOffice*" or class="libreoffice*"
will open at the viewport to the right.
Nothing should be drawn on the current viewport.

Part #1: Opening a Writer document from a prompt. The splash screen class is "soffice", so it doesn't match my compiz rules.

Part #2: Writer briefly draws a screen on the correct viewport, but then immediately redraws on the current, incorrect viewport. The redraw is in progress here. That briefly-extant window matches the 'class=LibreOffice*' rule but not 'class=libreoffice*'.

Part #3: Final state. This window matches the 'class=libreoffice*' placement rule, which obviously was ignored. (...And this rule definitely matches - I can use it to tweak other properties, such as window opacity.)


* xprop on the splash screen (#1):

WM_CLASS(STRING) = "soffice", "Soffice"
WM_ICON_NAME(STRING) = "LibreOffice 3.6"
_NET_WM_ICON_NAME(UTF8_STRING) = "LibreOffice 3.6"
WM_NAME(STRING) = "LibreOffice 3.6"
_NET_WM_NAME(UTF8_STRING) = "LibreOffice 3.6"

* xprop on #2...well, my reflexes aren't that fast.

* xprop on the open Writer doc window (#3):

WM_CLASS(STRING) = "VCLSalFrame", "libreoffice-writer"
WM_ICON_NAME(STRING) = "test_doc.odt - LibreOffice Writer"
_NET_WM_ICON_NAME(UTF8_STRING) = "test_doc.odt - LibreOffice Writer"
WM_NAME(STRING) = "test_doc.odt - LibreOffice Writer"
_NET_WM_NAME(UTF8_STRING) = "test_doc.odt - LibreOffice Writer"


(I'm running Ubuntu 11.04/Compiz 0.9.4.0)
Comment 3 bfoman (inactive) 2012-10-25 12:11:48 UTC
Please do not update version field - see http://wiki.documentfoundation.org/BugReport_Details#Version. A note as a comment is enough.

Changed back to initial value, platform Linux.
Comment 4 Thomas van der Meulen [retired] 2013-07-03 05:43:09 UTC
Is bug 66526 related to this, if it is please set it to a duplicate and this bug as new -2 people with the same bug-, thank you :)
Comment 5 retired 2013-07-03 09:51:01 UTC
LO opens where I left off on OS X 10.8.4. Tested with 2 monitors.
Comment 6 91kk91 2013-08-20 18:16:06 UTC
I can confirm this bug under Ubuntu 12.04.2 LTS with LXDE/Openbox. 

LibreOffice overrides all settings imposed on it by the window manager (window placement under mouse). Even forcing the window position through an Openbox config modification (position force="yes") does not work.


System information:

$apt-cache policy libreoffice
libreoffice:
  Installed: 1:3.6.6-0ubuntu1~precise1~ppa1
  Candidate: 1:3.6.6-0ubuntu1~precise1~ppa1

$ apt-cache policy openbox
openbox:
  Installed: 3.5.0-7~precise
  Candidate: 3.5.0-7~precise

$ uname -a
Linux 91KKSYS 3.5.0-39-generic #60~precise1-Ubuntu SMP Wed Aug 14 15:38:41 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Comment 7 tommy27 2013-08-25 13:49:54 UTC
setting status as NEW according to previous comment.

I ask feedback from the bug reporters: do you still see this issue with recent 3.6.7 or 4.0.5 or 4.1.0 releases?

unfortunately I have just 1 monitor and I can't test.
Comment 8 tommy27 2013-08-25 13:50:06 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2015-04-01 14:40:22 UTC Comment hidden (obsolete)
Comment 10 tommy27 2016-04-16 07:22:56 UTC Comment hidden (obsolete)
Comment 11 QA Administrators 2017-05-22 13:22:29 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2020-04-08 03:33:44 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2022-05-21 03:39:47 UTC
Dear mcq_public,

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 with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

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) from https://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: https://web.libera.chat/?settings=#libreoffice-qa

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

Warm Regards,
QA Team

MassPing-UntouchedBug