LibreOffice doesn't remember window size when running under Wayland

[Jonathan Kamens]

1. Open any LibreOffice document, e.g., a Writer or Calc document.
2. Make the window a reasonable, non-maximized size.
3. Maximize the window.
4. Close LibreOffice.
5. Open the document again; it will open maximized.
6. Un-maximize the window.
7. Observe how the window has a ridiculously small size, not its previously unmaximized size.

LibreOffice or gnome-shell bug? Not sure.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: libreoffice-core 1:5.4.1-0ubuntu1
ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
Uname: Linux 4.13.0-16-generic x86_64
ApportVersion: 2.20.7-0ubuntu3.1
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed Nov 1 16:21:29 2017
InstallationDate: Installed on 2017-05-19 (166 days ago)
InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
SourcePackage: libreoffice
UpgradeStatus: Upgraded to artful on 2017-10-20 (12 days ago)

[Jeff Fortin Tam (kiddo)]

Description:
In Fedora 25, whether on X or Wayland, with the GTK3 version of LibreOffice, if you start your LOo app maximized, once you demaximize it it will become minuscule (something like 400x200 pixels) instead of using the last saved size.

In contrast, if you start the app with a non-maximized window, when you maximize and unmaximize it it will retain its previous size.

Actual Results:

Expected Results:

Reproducible: Always

User Profile Reset: No

Additional Info:

User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0

[Beluga (beluga)]

No repro on Arch Linux or Ubuntu

Arch:
Version: 5.4.0.0.alpha0+
Build ID: a564821eb9e991774195120e6965b2a8b1419dc5
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: gtk3;
Locale: fi-FI (fi_FI.UTF-8); Calc: group

Ubuntu:
Version: 5.2.3.3
Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default;
Locale: en-US (en_US.UTF-8); Calc: group

[Xiscofauli (xiscofauli)]

Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.

[Jonathan Kamens (jik)]

This might be eligible for a `regression-release` tag since 17.04 didn't have this problem.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jan (jan-redhat-bugs)]

I'm using a multi display setup. A regular display and a HiDPI display.
For some reason Libreoffice windows sometimes resize to completely minimized (only menu visible) when doubleclicking on the title bar.

This minimized window is not visible when activating it (it seems that it is in an area that is not covered by the virtual desktop of the two displays. To solve this, I have to move the window from one display to the other.

[Jan Vlug (jan-vlug)]

I confirm this issue on 5.4.4.1-1.fc27

Some system info:
Fedora 27, Wayland, 2 displays: regular and HiDPI

See also: https://bugzilla.redhat.com/show_bug.cgi?id=1526696

[Jan (jan-redhat-bugs)]

See also: https://bugs.documentfoundation.org/show_bug.cgi?id=104371

[Olivier Tilloy (osomon)]

I cannot reproduce the issue with the latest version of LibreOffice (6.1.3.2) on Ubuntu 19.04.

@Jonathan: you originally reported this bug against Ubuntu 17.10, which is EOL. Can you still see it on 18.04 ?

[Jonathan Kamens (jik)]

I am not able to reproduce this in 18.10. I no longer have an 18.04 machine to test on.

[Olivier Tilloy (osomon)]

Thanks. I'm marking the bug fixed, per your comment. If you get a chance to test that on a 18.04 machine, please share your experience here.

[Heiko-tietze-g (heiko-tietze-g)]

With a fresh profile, modules start maximized. That's not a good window size for large screens, so users have to resize. Doing this with Calc ends up in a tiny and hard to spot square (title bar only). We should a) use a default windows size according the OS and b) at least define a minimum size for Calc. AFAIR, it's not an issue for other modules.

[Os-x (os-x)]

Hello Heiko,
Thank you for reporting this. I confirm it with:
Version: 6.3.0.0.alpha1+
Build ID: 77ae0abe21f672cf4b7d2e069f1d40d20edc49a7
CPU threads: 4; OS: Linux 4.9; UI render: default; VCL: gtk3;
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-31_15:33:33
Locale: en-GB (en_GB.utf8); UI-Language: en-US
Calc: threaded

When minimizing it the window size changes to really tiny square around 12px.

Regarding starting as maximized I don't see it as an issue because the window size will be preserved for the next start. User will only have to change it once and most people don't have large screens.

[Heiko-tietze-g (heiko-tietze-g)]

Since Xisco requests input from UX, let's talk about. I work on a large super-wide screen where the modules are set to the maximum screen size - makes not much sense and I always resize first to ~1600x1200px, which is a 4/3 ratio.

At least Windows has a application size policy with PreferredLaunchViewSize and we should follow this.

Last but not least we define as minimum required resolution 1280x768px in [1], that could also be taken into account.

Of course, the actual value has to be responsive to the resolution, and the default scaling should work with HiRes too (8k screens might come in some years). And we should maximize in case of very small screens.

[1] https://wiki.documentfoundation.org/Design/MenuBar

[Heiko-tietze-g (heiko-tietze-g)]

We discussed the topic in the design meeting and agreed on the proposal, considering a 16:9 ration, which is better suited for movies, and less space such as 50%, which would be too small. Any minimum value is an advantage over the zero size that might appear to users as broken (therefore I raise the importance).

[Heiko-tietze-g (heiko-tietze-g)]

SetMinOutputSizePixel() is implemented for include/vcl/syswindow and include/sfx2/dockwin but not include/vcl/window.hxx. And this function should receive the actual value from the OS/DE. Probably an easy hack for more experienced developers. Thanks jmux for the code pointers.

[Xiscofauli (xiscofauli)]

@Caolán, I thought you might be interested in this issue...

[Caolan-mcnamara (caolan-mcnamara)]

SetMinOutputSizePixel sets the minimum size below which a window cannot be shrunk, which is probably not whats wanted.

[Qa-admin-q (qa-admin-q)]

Dear Jean-François Fortin Tam,

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 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

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

Warm Regards,
QA Team

MassPing-UntouchedBug

[J-Paul BERARD (arverne)]

Still present in
LibreOffice Version: 6.2.6.2
Build ID: 1:6.2.6-0ubuntu0.19.04.1

[J-Paul BERARD (arverne)]

The bug is no more present in this version.
BUT, the behavior is not really the good one : when you unmaximize the window, it doesn't come back to the previous size but to a nearly maximum size.

Version: 6.3.2.2
Build ID: 1:6.3.2-0ubuntu1
Ubuntu GNOME WAYLAND 19.10

[Olivier-crete-x (olivier-crete-x)]

I'm still reproducing this on Fedora 31 with the 6.3.4.2-2.fc31 build.

I think the other sub-bug here is that LibreOffice lets me resize the window to a size smaller than the UI elements.

[Buzea-bogdan (buzea-bogdan)]

In my case I had the window with 2 mm wight and 1 cm height. It is very hard to notice that this is a window. You can not edit in Calc in 0,02*1 cm... So, a default minim of 4 cm * 4 cm, or maybe 3*3 cm could be done. From my POV a 3*3 cm would be a minimum, else you can not see any cell in any file.

[Buzea-bogdan (buzea-bogdan)]

*** Bug 136655 has been marked as a duplicate of this bug. ***

[Buzea-bogdan (buzea-bogdan)]

*** Bug 136662 has been marked as a duplicate of this bug. ***

[Menno (mlabakker)]

I am experiencing this on Kubuntu 20.04.
Version: 6.4.6.2
Build ID: 1:6.4.6-0ubuntu0.20.04.1
CPU threads: 4; OS: Linux 5.4; UI render: GL; VCL: kf5;
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: CL
Operating System: Kubuntu 20.04
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8
Kernel Version: 5.4.0-52-generic
OS Type: 64-bit
nVidia GeForce GTX650Ti, driver 450.80.02

I have already used configure window settings - size & position -remember position / remember size
and configure application application settings - size & position -remember position / remember size.
However it keeps opening smaller than I want it to. Even manually altering the size here has no effect.

Also, dragging the window to the desired size is very slow to draw.
Opening a document also take several seconds.
This did not happen when I was using Mint KDE 17.3. Documents opened instantaneously, window remembered size, resizing fast.

[Koen Roggemans (koen-roggemans)]

I think this bug describes the behaviour on https://askubuntu.com/questions/1274365/windows-of-an-application-have-minimum-size-and-i-cant-find-the-window-anymore

We have noticed that with several of our students on Ubuntu 20.04 with LO 7.0.4.2

[Jarosław Rafa (raj001)]

I had this bug in a bit different scenario. I was running Calc maximized, and when I tried to import a CSV file by double-clicking on it, after going through the import dialog, my window minimized to a very small square.
This is reproduced everytime I run Calc maximized and import a CSV file via double-click.
If Calc was not maximized before import, there was no issue.

[Jeff Fortin Tam (kiddo)]

This bites me almost daily because whenever I open Calc by opening a document, and it opens maximized, and I un-maximize the window (Super+downarrow key in GNOME), it ends up becoming a 1x1 pixels (or something like that) micro window that is barely noticeable.

Non-technical users (like many people in my extended family, who don't know the keyboard shortcuts to un/maximimize) would be pretty flustered by that and will end up with a "broken" app practically speaking.

> SetMinOutputSizePixel sets the minimum size below which a window cannot be shrunk, which is probably not whats wanted.

Actually that's exactly what I would want, at least as the fallback for undefined states where the app can't figure out what the appropriate default size would be. Make it enforce a hard minimum of 600x400 at the very least.

Why would anyone ever want to have a LibreOffice Calc/Writer/etc. main window sized anywhere smaller than 640x480 pixels? It seems to me that it could safely be assumed to be the absolute minimum to which a main app window can no longer be shrunk, because it's no longer usable below that size (even the toolbars would eat half of the height). Even phones these days have at least 720px in one dimension or the other, and no VGA output that I know shrinks below 640x480 even in disaster scenarios.

[Ougs (ougs)]

(In reply to Jean-François Fortin Tam from comment #11)
> This bites me almost daily because whenever I open Calc by opening a
> document, and it opens maximized, and I un-maximize the window
> (Super+downarrow key in GNOME), it ends up becoming a 1x1 pixels (or
> something like that) micro window that is barely noticeable.
>
> Non-technical users (like many people in my extended family, who don't know
> the keyboard shortcuts to un/maximimize) would be pretty flustered by that
> and will end up with a "broken" app practically speaking.
>
> > SetMinOutputSizePixel sets the minimum size below which a window cannot be shrunk, which is probably not whats wanted.
>
> Actually that's exactly what I would want, at least as the fallback for
> undefined states where the app can't figure out what the appropriate default
> size would be. Make it enforce a hard minimum of 600x400 at the very least.
>
> Why would anyone ever want to have a LibreOffice Calc/Writer/etc. main
> window sized anywhere smaller than 640x480 pixels? It seems to me that it
> could safely be assumed to be the absolute minimum to which a main app
> window can no longer be shrunk, because it's no longer usable below that
> size (even the toolbars would eat half of the height). Even phones these
> days have at least 720px in one dimension or the other, and no VGA output
> that I know shrinks below 640x480 even in disaster scenarios.

I'm also experiencing exactly the same issue, running KDE Neon. In fact, I cannot even find the 'pixel' on my display and need to force-close the app. It really is an absurd situation - clearly a bug and not a feature!

[Tim Passingham (tim-8aw3u04umo)]

I'm on ubuntu 21.04, wayland. LO now opens files almost full size, but not quite within the screen size, slightly to the right, so I have to move the window (using the top bar) before I can properly resize it, and I have to do this every single time.

This seems to have changed in the most recent LO update. I have now uninstalled LO gtk3 and gnome, which makes things slightly better. Having done that I am now on:

Version: 7.1.5.2 / LibreOffice Community
Build ID: 10(Build:2)
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: x11
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Ubuntu package version: 1:7.1.5~rc2-0ubuntu0.21.04.1~lo1
Calc: threaded

[Michael-warner-ut+libreoffice (michael-warner-ut+libreoffice)]

*** Bug 145545 has been marked as a duplicate of this bug. ***

[5-jonc (5-jonc)]

Hi there

As far as I can see, this issue is still live and in fact, I experience it on a regular basis. I also have a group of users at my company that complain about it.

That being the case, I'm interested in hearing from someone on the project team to understand how I can assist with getting it resolved.

Many thanks,
Jon

[Stephane-guillou-i (stephane-guillou-i)]

Created attachment 176440
screenshot of minimised Calc window on Ubuntu 18.04

I can reproduce the issue by opening Calc (either opening the application or opening a document with Calc) with a recent master build:

Version: 7.3.0.0.alpha1+ / LibreOffice Community
Build ID: eec32be26d5d5805c1cb8cb53ce9702c04829819
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Not only Calc is useless at this size (I am only able to click the "close document" button), but it might look to others like it has crashed if they don't directly spot where the tiny window is.

Attached screenshot shows panel indicators for size reference.

[WHK (yan-uniko-102)]

Same problem using Ubuntu 20.04 and libreoffice 7.2.2.2.

[6-michael-h (6-michael-h)]

Same issue for quite some time now. Not only with Calc, but with Writer.

Ubuntu 21.04
LibreOffice Version 7.1.7.2

The window ends up being about 1 pixel wide. I can drag it larger, but very disruptive and happens frequently.

I'll (try to) post an image.

[6-michael-h (6-michael-h)]

Created attachment 177624
Pix of the intensely small LibreOffice window

[Buzea-bogdan (buzea-bogdan)]

I am coming back with the idea to calculate a minimum width/height when LibreOffice is usable, and if the windows is going back to 1 mm, that limit will force to be bigger.

Maybe a minimum of 5 cm width and 4 cm heigh (it's the title and 2 rows of icons) nothing usable still, but enough that we can see LibreOffice window IS on the screen).

[draco (draco31-fr)]

*** Bug 134315 has been marked as a duplicate of this bug. ***

[draco (draco31-fr)]

*** Bug 148637 has been marked as a duplicate of this bug. ***

[draco (draco31-fr)]

Hello,

This bug is very anoying and still present in latest version as shown by latest duplicates reports.

Unfortunately, as screens becomes wider and uses higher dpi resolution, it is more and more difficult to find the restored window.

This leads users to think it is freezed or anything unrecoverable and kill process, loosing their work.

IMHO, I would expect to view at least the 'File' menu in order to save my work or quit properly, and the title bar button to maximize/close the window.

I agree with the minimum size of 640x480 in last resort.
I didn't see any screen smaller even considering oldest hardware capable of running current version of LO.

May I ask what is expected by the UI team to take a decision ?

Best regards

[Heiko-tietze-g (heiko-tietze-g)]

(In reply to draco31.fr from comment #22)
> May I ask what is expected by the UI team to take a decision ?
No need for further input from the design team. Seeking for volunteers to implement it.

[Mattkse (mattkse)]

No repro on Windows 11. Is this a Linux-only bug?

[Ilmari-lauhakangas (ilmari-lauhakangas)]

(In reply to Matt K from comment #24)
> No repro on Windows 11. Is this a Linux-only bug?

Yes indeed, the OS field was incorrect.

[Buzea-bogdan (buzea-bogdan)]

Repro today on a new Ubuntu 22.04 install with
Version: 7.5.0.0.alpha0+ / LibreOffice Community
Build ID: 5c68399e6bea3aa18477487400f8bb143d6ed84e
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded

[Logistikka (logistikka)]

confirmed for Impress, too.

Version: 7.4.1.1 / LibreOffice Community
Build ID: 40(Build:1)
CPU threads: 16; OS: Linux 5.18; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Debian package version: 1:7.4.1~rc1-3
Calc: threaded

[Stephane-guillou-i (stephane-guillou-i)]

Removing "Calc" from summary and component as issue has been reported for Writer and Impress as well (as well as Dray in another report that I will probably mark as duplicate).

Earliest known version from Description is 6.3 alpha1+, using "6.3 all versions" as it is not available.

[Stephane-guillou-i (stephane-guillou-i)]

*** Bug 150079 has been marked as a duplicate of this bug. ***

[Document-foundation-bugs (document-foundation-bugs)]

This may affect Windows. Bug 99112 describes related behaviour; this may be a duplicate.

[Jg-jguk (jg-jguk)]

There's a lot of messages, but no fix. Is there anyone to work on this? It's easy enough to even check for (0,0) and change that to 600x600 so at least it will be visible if the real issue can't be solved today. I'll pay a $50 bug bounty for this fix to be committed and integrated.

[Ilmari-lauhakangas (ilmari-lauhakangas)]

The comments from this month might be about bug 150856, which was a recent regression and is fixed for 7.4.2.

Heiko: how is the behaviour for you now? In Safe mode on Linux with any of the UIs, they do *not* start maximised. Same for Windows.

Bug 99112 is about remembering the size across sessions, while this report is about what happens with a fresh profile in a single session.

Arch Linux 64-bit
Version: 7.4.1.2 / LibreOffice Community
Build ID: 40(Build:2)
CPU threads: 8; OS: Linux 5.19; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
7.4.1-2
Calc: threaded

Arch Linux 64-bit
Version: 7.5.0.0.alpha0+ / LibreOffice Community
Build ID: f5c6ef40dd494f6984c6ed784fccc02806999836
CPU threads: 8; OS: Linux 5.19; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 7 September 2022

Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 00c5b0ca9264c5440bc70a68c425127ba5a47003
CPU threads: 2; OS: Windows 10.0 Build 19044; UI render: default; VCL: win
Locale: fi-FI (fi_FI); UI: en-US
Calc: threaded Jumbo

[Logistikka (logistikka)]

On Debian, I confirm that upgrading to LO 7.4.2.1 from experimental branch today fixes this issue. Thank you. LO windows will open one last time with minimal size, though. After manually resizing them one last time they will reopen maximized upon restart, as expected.

At least on Debian I never experienced this bug with GNOME or Cinnamon Desktop; only with KDE Plasma.

fixed in:
Version: 7.4.2.1 / LibreOffice Community
Build ID: 40(Build:1)
CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Debian package version: 1:7.4.2~rc1-2

[Heiko-tietze-g (heiko-tietze-g)]

(In reply to Buovjaga from comment #32)
> Heiko: how is the behaviour for you now? In Safe mode on Linux with any of
> the UIs, they do *not* start maximised. Same for Windows.

Cannot test on Linux this week. All good on macOS, but prolly never was an issue.

[Stephane-guillou-i (stephane-guillou-i)]

The only way I consistently reproduce this bug is by following steps similar to comment 10, when opening a LibreOffice component involves getting through a dialog first. For example:

1. open Calc
2. maximise the window
3. close Calc
4. Open a CSV file with Calc
5. Once passed the import dialog, unmaximise (aka "restore down") the Calc window

But also:

1. open Base
2. maximise the window
3. close Base
4. Open Base again
5. Once passed the database creation dialog, unmaximise (aka "restore down") the Base window

Result: the windows is tiny.

However, it is possible to resize the window to an extremely small size in any LO component.

[Heiko-tietze-g (heiko-tietze-g)]

*** Bug 151313 has been marked as a duplicate of this bug. ***

[Heiko-tietze-g (heiko-tietze-g)]

Seems to be solved with bug 150779.

[Stephane-guillou-i (stephane-guillou-i)]

(In reply to Heiko Tietze from comment #37)
> Seems to be solved with bug 150779.

Sorry Heiko, I can still reproduce with:

Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: a41c82407bbb73a4d87070326485ec4b4e954a65
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

and:

Version: 7.4.2.3 / LibreOffice Community
Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

following the steps in comment 35.

[Le_MoRT (jlrpalomar)]

Reproduced on Libreoffice 7.4.2 on Linux Mint 21 Cinnamon 5.4.12

Following the steps of comment 35 as stated above

Please, prioritize this issue, it's been there for ages and it's 100% possible to reproduce

[simon coleman (simondcoleman)]

Very reproducible for LibreOffice 7.4.3 on Ubuntu 20.04 LTS (patched to date)
Is very annoying, very noticeable when using CSV.
Gnome shortcuts to resize the window in https://askubuntu.com/questions/1275213/libreofficecalc-window-is-shrunk-to-a-line-and-is-unclickable

I haven't investigated the output of SetMinOutputSizePixel but it looks like the end window it produces is the smallest possible desktop window, not the smallest window usable in Calc. Which even sounds like the wrong choice.

It's pretty much impossible to use without keyboard shortcuts on "normal" 1920x1080 monitors.

Surely after 3.5yrs the answer is not "best possible for all resolutions" but "anything that will work with many common resolutions" since I think the current approach is probably not workable for any resolution.

[Kaki87 (kaki87)]

Hello,

Reproduced on Ubuntu 22.04

Press Ctrl-Super-ArrowUp to put window back in maximized mode.

However, totally unable to resize the window in unmaximized mode, thus critical bug.

Thanks

[Kaki87 (kaki87)]

EDIT: Reproduced on Ubuntu **Unity** 22.04 (not GNOME or other).

[Stephane-guillou-i (stephane-guillou-i)]

Already reproduced following comment 35 steps in:

Version: 6.0.0.3
Build ID: 64a0f66915f38c6217de274f0aa8e15618924765
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk2;
Locale: en-AU (en_AU.UTF-8); Calc: group

However, my steps don't give completely consistent results, so I'm not calling it a regression based on inability to reproduce in earlier versions. More consistent STR welcome.

Marking as depending on bug 97894 as a fix that covers all bases (startup, maximising/unmaximising, and manual resizing) should also fix this.

[Jg-jguk (jg-jguk)]

Just an idea, can't it at least have a min 640x480 min size fallback? At least it's easier to spot it and resize by hand.

[Stephane-guillou-i (stephane-guillou-i)]

*** Bug 155955 has been marked as a duplicate of this bug. ***

[Libreoffice-commits (libreoffice-commits)]

Amin Irgaliev committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/431dc963a0d18341c9b4869a2a64009b7ff7f699

tdf#125543 Fix window size in GTK3 plugin

It will be available in 24.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

[Eyalroz1 (eyalroz1)]

(In reply to Commit Notification from comment #46)
> Affected users are encouraged to test the fix and report feedback.

First, Amin, thanks for the patch. Unfortunately this is not something I experience frequently, so not so easy to reproduce the situation where I saw this. Encouraging other dupe authors to try though...

[Russell-g-almond (russell-g-almond)]

I am no longer seeing the problem. When I open a new window, it is not maximized. If I maximize the window and then un-maximize it by dragging the title bar, it changes to a sensible size.

Running Libre office under 7.3.7.2,
Pop_OS 22.04
Gnome 42.5

Note, I'm currently running under Wayland, but was running under X windows when the problem occurred.

So, works-for-me.

[Stephane-guillou-i (stephane-guillou-i)]

Thank you for the patch, Amin.
If you don't have follow-up commits, please feel free to mark as "resolved".

Everyone affected, especially if you come from a duplicate report: please test a recent master build and see if you can still see the issue -> https://dev-builds.libreoffice.org/daily/master/current.html
Given the number of duplicates, it would be good to get lots of testers.

Noting that Heiko was talking about a fresh profile in Comment 0, which matches bug 155955 (recently fixed).

Using Comment 35 steps, I can't reproduce.

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: d74344f6cae0cf1c12f08249c8f49be1374fb98f
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

[Irgaliev01 (irgaliev01)]

These fixes affect only the GTK3 plugin. Please test bug reproduction on other plugins: kf5, x11, gen, etc.

[Irgaliev01 (irgaliev01)]

If the bug is still reproducible, please let us know the steps that made the bug for you.

[Si Dedman (si-dedman)]

Worked for me, thanks all.

For anyone like me who was born with congenital dumbitis: you need to set the default program to LO dev otherwise it'll keep using default LO.

[Libreoffice-commits (libreoffice-commits)]

Amin Irgaliev committed a patch related to this issue.
It has been pushed to "libreoffice-7-6":

https://git.libreoffice.org/core/commit/ca93bbe8703bd6cf2aef8a649b0db2524a61afe9

tdf#125543 Fix window size in GTK3 plugin

It will be available in 7.6.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

[Stephane-guillou-i (stephane-guillou-i)]

Jeff, Koen, Olivier and Jan: can you please test version 7.6.2 or above? With bug 125543 fixed, I wonder if the issue is also fixed for you.
Thank you.

[J-Paul BERARD (arverne)]

With LO 7.6.2.1 and Ubuntu 23.10 (main UI) Wayland :
I create a Writer file with a medium window. I maximize the window and quit LO.
I open again the same file : the window is maximized. When I un-maximize the window, it doesn't come back to the medium previous size but to a more maximized size ! I mean, the size of the window increases again going behind the dock.
If I maximize again and un-maximize a second time, the window comes back to a medium size but not the same that the initial one.
But not the very small window we saw before.

Thanks

[Koen Roggemans (koen-roggemans)]

I can't reproduce the problem with a fresh 7.6.2.1 installation.
It looks like it's solved.
Thanks!

[Stephane-guillou-i (stephane-guillou-i)]

Thank you Koen!
Let's mark as a duplicate of bug 125543 then.
However, if Jeff, Jan or Olivier can still reproduce, please provide steps and version information.

*** This bug has been marked as a duplicate of bug 125543 ***

[Stephane-guillou-i (stephane-guillou-i)]

*** Bug 104371 has been marked as a duplicate of this bug. ***

[Ben-grote (ben-grote)]

 Reopening this bug.

An update to a newer version via the PPA. The Calc seems to be steady but I've appeared to still be having the issue on LibreOffice Draw even after an update

[Ilmari-lauhakangas (ilmari-lauhakangas)]

(In reply to ben.grote from comment #55)
> Reopening this bug.
>
> An update to a newer version via the PPA. The Calc seems to be steady but
> I've appeared to still be having the issue on LibreOffice Draw even after an
> update

Please copy and paste here the contents of your Help - About by clicking the copy button. This allows us to know more about your system.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.

[Ilmari-lauhakangas (ilmari-lauhakangas)]

*** Bug 158964 has been marked as a duplicate of this bug. ***

[Jeff Fortin Tam (kiddo)]

It partially works for me in version 24.2 from Flathub, on Wayland GNOME 45 / Fedora 39.

What works: it doesn't become minuscule.

What doesn't work optimally: it seems the maximization state is maybe not saved independently from width/height, because sometimes when you unmaximize it, either...

* It unmaximizes to the previous window width/height (correct behavior), or;
* It unmaximizes to the "maximized window's width/height" (incorrect behavior)

See this demonstration video showing both situations with LibreOffice Calc 24.2:
https://youtu.be/dv8gb1GljzU

Further reference that might help as inspiration for implementation, i.e. how it works in GNOME apps at least: https://developer.gnome.org/documentation/tutorials/save-state.html (you can see there that the maximization state is saved independently from width/height, but also you need to infer that width/height shouldn't get saved while in maximized state, only in windowed state)

---

Version: 24.2.0.3 (X86_64) / LibreOffice Community
Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1
CPU threads: 8; OS: Linux 6.6; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Flatpak
Calc: threaded

[Jeff Fortin Tam (kiddo)]

I forgot to mention: the behavior observed in my comment #58 above is consistent across the apps, i.e. on my end it behaves the same in Draw like it does in Calc or Writer; I don't get minuscule windows on demaximizing, but the window size restoration is still a coin toss between "what it was" and "what is the width and height of the maximized window".

[Stephane-guillou-i (stephane-guillou-i)]

Ben didn't provide version details in comment 55.

Jeff, thank you for the follow-up, but because this report is about the barely visible, minuscule window issue, and because there's 60+ comments, let's see if your issue is already better described elsewhere, or if it needs a fresh start in a new report, with clear steps.
Thank you!