Bug 125543 - unmaximizing the window reduces to minimal width and height, making window barely visible (Linux-only)
Summary: unmaximizing the window reduces to minimal width and height, making window ba...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.3 all versions
Hardware: All Linux (All)
: high normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 134315 136655 136662 145545 148637 150079 151313 (view as bug list)
Depends on:
Blocks: Maximized-Window
  Show dependency treegraph
 
Reported: 2019-05-28 07:50 UTC by Heiko Tietze
Modified: 2022-11-25 11:44 UTC (History)
24 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
screenshot of minimised Calc window on Ubuntu 18.04 (84.70 KB, image/png)
2021-11-23 06:28 UTC, Stéphane Guillou (stragu)
Details
Pix of the intensely small LibreOffice window (216.27 KB, image/png)
2022-01-17 23:57 UTC, Michael Turner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Heiko Tietze 2019-05-28 07:50:09 UTC
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.
Comment 1 Usama 2019-06-16 03:43:24 UTC
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.
Comment 2 Heiko Tietze 2019-06-27 08:04:30 UTC
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
Comment 3 Heiko Tietze 2019-07-11 13:12:56 UTC
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).
Comment 4 Heiko Tietze 2019-07-15 11:22:32 UTC
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.
Comment 5 Xisco Faulí 2019-07-18 17:36:02 UTC
@Caolán, I thought you might be interested in this issue...
Comment 6 Caolán McNamara 2019-07-22 15:50:39 UTC
SetMinOutputSizePixel sets the minimum size below which a window cannot be shrunk, which is probably not whats wanted.
Comment 7 BogdanB 2020-08-31 09:24:09 UTC
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.
Comment 8 BogdanB 2020-09-11 04:08:56 UTC
*** Bug 136655 has been marked as a duplicate of this bug. ***
Comment 9 BogdanB 2020-09-11 19:42:17 UTC
*** Bug 136662 has been marked as a duplicate of this bug. ***
Comment 10 Jarosław Rafa 2021-02-08 16:28:16 UTC
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.
Comment 11 Jeff Fortin Tam 2021-04-30 15:55:07 UTC
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.
Comment 12 Dan 2021-05-23 12:58:29 UTC
(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!
Comment 13 Michael Warner 2021-11-05 13:58:18 UTC
*** Bug 145545 has been marked as a duplicate of this bug. ***
Comment 14 Jon Chamberlain 2021-11-11 23:25:06 UTC
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
Comment 15 Stéphane Guillou (stragu) 2021-11-23 06:28:05 UTC
Created attachment 176440 [details]
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.
Comment 16 yan102 2021-11-23 12:21:23 UTC
Same problem using Ubuntu 20.04 and libreoffice 7.2.2.2.
Comment 17 Michael Turner 2022-01-17 23:56:35 UTC
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.
Comment 18 Michael Turner 2022-01-17 23:57:39 UTC
Created attachment 177624 [details]
Pix of the intensely small LibreOffice window
Comment 19 BogdanB 2022-01-26 15:38:28 UTC
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).
Comment 20 draco31.fr 2022-04-26 06:49:06 UTC
*** Bug 134315 has been marked as a duplicate of this bug. ***
Comment 21 draco31.fr 2022-04-26 06:50:30 UTC
*** Bug 148637 has been marked as a duplicate of this bug. ***
Comment 22 draco31.fr 2022-04-26 07:12:58 UTC
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
Comment 23 Heiko Tietze 2022-04-26 07:26:20 UTC
(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.
Comment 24 Matt K 2022-08-06 00:00:55 UTC
No repro on Windows 11.  Is this a Linux-only bug?
Comment 25 Buovjaga 2022-08-06 07:18:26 UTC
(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.
Comment 26 BogdanB 2022-08-06 14:13:52 UTC
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
Comment 27 Oliver Grimm 2022-09-06 19:48:52 UTC
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
Comment 28 Stéphane Guillou (stragu) 2022-09-19 19:58:44 UTC
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.
Comment 29 Stéphane Guillou (stragu) 2022-09-19 20:08:13 UTC
*** Bug 150079 has been marked as a duplicate of this bug. ***
Comment 30 Adam Piggott 2022-09-24 12:24:08 UTC
This may affect Windows. Bug 99112 describes related behaviour; this may be a duplicate.
Comment 31 Jonny Grant 2022-09-24 12:36:25 UTC
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.
Comment 32 Buovjaga 2022-09-24 14:28:48 UTC
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
Comment 33 Oliver Grimm 2022-09-24 21:59:00 UTC
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
Comment 34 Heiko Tietze 2022-09-26 09:23:23 UTC
(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.
Comment 35 Stéphane Guillou (stragu) 2022-10-08 21:45:48 UTC
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.
Comment 36 Heiko Tietze 2022-11-22 12:30:05 UTC
*** Bug 151313 has been marked as a duplicate of this bug. ***
Comment 37 Heiko Tietze 2022-11-22 12:30:41 UTC
Seems to be solved with bug 150779.
Comment 38 Stéphane Guillou (stragu) 2022-11-22 13:42:28 UTC
(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.