Description: The phenomenon appeared a few versions earlier. If Libreoffice exited in fullscreen on the second screen, it will start again on the first screen next time. If it was not ended in full screen, it remembers the last window position. Steps to Reproduce: 1. Starting Writer. 2. Move the program window to the second screen and fullsize the window. 3. Close the program. 4. Restart Writer. Actual Results: Restarting opens the program on the first screen in fullsize-mode. Expected Results: Writer should open on the last postion: on the second screen. Reproducible: Always User Profile Reset: No Additional Info: Not needed. The phenomenon appeared a few versions earlier, too.
Confirmed, manifests in the user profile .XCU for the ooSetupFactoryWindowAttributes where direct closing (<Ctrl>+Q) a module placed in FullScreen mode (<Ctrl>+<Shift>+J for swriter.exe or scalc.exe) appends a mode "68" to the xy positions of the window in the .XCU setup. mode "1" is standard sized window mode "4" is Maximized sized window I don't think mode "68" is being parsed correctly (but is applied for both Writer and Calc sessions so not spurious), and on relaunch of the module the fallback is to mode "4" with positioning from 0,0 window reference. It is more noticeable with a multi-head system, but the mode "68" --> "4" affects single screen as well (just not as obvious). Believe this comes from the refactoring of the mbFullScreen in https://gerrit.libreoffice.org/c/core/+/135809 and friends. Related for 7.4 in see-also bug 150236, but this remains for 7.5 and trunk against 7.6 @Jan-Marek, could you have a look. =-testing-= Build ID: 74dc2ac66f0130bcd77cf1bbe417b22865beb067 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Screen1 is 1920x1080 Screen2 is 1920x1080 =-taken from .xcu at different steps-= xcu after LO swriter.exe launch on screen1 and drag to screen2, swriter Maximized and doccument save <item oor:path="/org.openoffice.Setup/Office/Factories/org.openoffice.Setup:Factory['com.sun.star.text.TextDocument']"><prop oor:name="ooSetupFactoryWindowAttributes" oor:op="fuse"><value>1920,29,1920,1051;4;,,,;</value></prop></item> Other modules pick up x-positions on the screen2, i.e. > 1920 xcu after <Ctrl>+Q close from swriter.exe Writer in FullScreen (<Ctrl>+<Shift>+J) mode on screen2 <item oor:path="/org.openoffice.Setup/Office/Factories/org.openoffice.Setup:Factory['com.sun.star.text.TextDocument']"><prop oor:name="ooSetupFactoryWindowAttributes" oor:op="fuse"><value>1924,4,1912,1072;68;,,,;</value></prop></item> xcu with launch of swriter.exe following close from FullScreen, opens to screen1 in Maximized mode <item oor:path="/org.openoffice.Setup/Office/Factories/org.openoffice.Setup:Factory['com.sun.star.text.TextDocument']"><prop oor:name="ooSetupFactoryWindowAttributes" oor:op="fuse"><value>0,29,1920,1051;4;,,,;</value></prop></item> same "68" mode for an scalc.exe launch from screen2 start, and Calc in FullScreen mode, then <Ctrl>+Q close <item oor:path="/org.openoffice.Setup/Office/Factories/org.openoffice.Setup:Factory['com.sun.star.sheet.SpreadsheetDocument']"><prop oor:name="ooSetupFactoryWindowAttributes" oor:op="fuse"><value>1924,4,1912,1072;68;,,,;</value></prop></item> xcu with launch of scalc.exe following close from FullScreen, opens to screen1 in Maimized mode <item oor:path="/org.openoffice.Setup/Office/Factories/org.openoffice.Setup:Factory['com.sun.star.sheet.SpreadsheetDocument']"><prop oor:name="ooSetupFactoryWindowAttributes" oor:op="fuse"><value>0,29,1920,1051;4;,,,;</value></prop></item>
Dear Alexander Berg, 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
(In reply to QA Administrators from comment #2) > Dear Alexander Berg, > > 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 Hello QA Administrators. The error still exists.
Testing Version: 25.2.1.2 (X86_64) / LibreOffice Community Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49 CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Direct closing <Ctrl>+Q from a full screen <Ctrl>+<Shift>+J module (Writer or Calc) still records the ooSetupFactoryWindowAttributes with other than "1", or "4" At this point it receives a "65", and on restart of the module it does not open to full screen--but it does position the document canvas within the app frame as if it were from full screen. I no longer have multi-monitors to work against. But there continues to be some issue with the configuration/placement of a module closed from full screen mode. Of course only Writer or Calc are affected.
(In reply to V Stuart Foote from comment #4) > Testing Version: 25.2.1.2 (X86_64) / LibreOffice Community > Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49 > CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: > Skia/Vulkan; VCL: win > Locale: en-US (en_US); UI: en-US > Calc: CL threaded > > Direct closing <Ctrl>+Q from a full screen <Ctrl>+<Shift>+J module (Writer > or Calc) still records the ooSetupFactoryWindowAttributes with other than > "1", or "4" > > At this point it receives a "65", and on restart of the module it does not > open to full screen--but it does position the document canvas within the app > frame as if it were from full screen. > > I no longer have multi-monitors to work against. > > But there continues to be some issue with the configuration/placement of a > module closed from full screen mode. Of course only Writer or Calc are > affected. It no longer is jumping to the 0,0 position and the app frame is positioning to and taking the x,y size as recorded to the ooSetupFactoryWindowsAttributes stanza--just the positioning of the document within the app frame is off.
(In reply to V Stuart Foote from comment #5) > (In reply to V Stuart Foote from comment #4) > > Testing Version: 25.2.1.2 (X86_64) / LibreOffice Community > > Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49 > > CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: > > Skia/Vulkan; VCL: win > > Locale: en-US (en_US); UI: en-US > > Calc: CL threaded > > > > Direct closing <Ctrl>+Q from a full screen <Ctrl>+<Shift>+J module (Writer > > or Calc) still records the ooSetupFactoryWindowAttributes with other than > > "1", or "4" > > > > At this point it receives a "65", and on restart of the module it does not > > open to full screen--but it does position the document canvas within the app > > frame as if it were from full screen. > > > > I no longer have multi-monitors to work against. > > > > But there continues to be some issue with the configuration/placement of a > > module closed from full screen mode. Of course only Writer or Calc are > > affected. > > It no longer is jumping to the 0,0 position and the app frame is positioning > to and taking the x,y size as recorded to the > ooSetupFactoryWindowsAttributes stanza--just the positioning of the document > within the app frame is off. I don't understand what this means. However, there was a time when it worked perfectly. QA Administrators wrote to me and asked if the bug still existed, to which I replied to his question.
(In reply to Alexander Berg from comment #6) > > I don't understand what this means. However, there was a time when it worked > perfectly. QA Administrators wrote to me and asked if the bug still existed, > to which I replied to his question. As in comment 4, "But there continues to be some issue with the configuration/placement of a module *closed from full screen mode*. Of course only Writer or Calc are affected."
(In reply to V Stuart Foote from comment #7) > (In reply to Alexander Berg from comment #6) > > > > > I don't understand what this means. However, there was a time when it worked > > perfectly. QA Administrators wrote to me and asked if the bug still existed, > > to which I replied to his question. > > As in comment 4, "But there continues to be some issue with the > configuration/placement of a module *closed from full screen mode*. Of > course only Writer or Calc are affected." Okay. That's it.