Reproducible with Version: 5.4.3.0.0+
Build ID: 3766aa5b3232beba4e4989696b6d19103ba0d62f
Threads CPU : 4; OS : Linux 4.4; UI Render : par défaut; VCL : gtk3; 
Ubuntu_16.04_x86-64
Locale : fr-FR (fr_FR.UTF-8); Calc: single

set status to NEW

works as expected with LO 5.4.1 from Ubuntu PPA, so regression

Best regards. JBF

set version to unspecified because 5.4.2.1 is not available in the dropdown list.

This is really quite an irritating issue.  I have to resize every window every single time I use my applications, and often having multiple windows open this is becoming a real nuisance (English understatement....).

It isn't 'critical' for sure, but for me it's more than 'normal'.

Still present in 5.4.2.2 and driving me slightly.....

Version: 5.4.2.2
Build ID: 1:5.4.2~rc2-0ubuntu0.17.04.1~lo1
CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: en-GB (en_GB.UTF-8); Calc: group

I thought to try this under Windows 10, LO version 5.4.2 rc1.  

The problem does not occur in this environment.

I don't know if this problem is specific to ubuntu, or generically under linux.

Couldn't reproduce this behavior with OpenSUSE 42.2 64bit rpm Linux and 
LO Version: 5.4.2.1
Build-ID: dfa67a98bede79c671438308dc9036d50465d2cb
CPU-Threads: 4; Betriebssystem:Linux 4.4; UI-Render: Standard; VCL: kde4; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

No repro either on 

Version: 5.4.1.2
Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527
Threads CPU : 8; OS : Mac OS X 10.12.6; UI Render : par défaut; 
Locale : fr-FR (fr_FR.UTF-8); Calc: group


so this sounds like it is an Ubuntu package problem.

@Tim : if you find the same problem with a TDF provided version, then please do re-open this report.

No repro either with

Version: 5.4.2.2
Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4
CPU threads: 4; OS: Mac OS X 10.13; UI render: default; 
Locale: fr-FR (fr_FR.UTF-8); Calc: group

Ok - Thanks, I was beginning to think it must be ubuntu.  

I've gone back to 5.4.1 just to make sure it was nothing else in my 17.04 ubuntu system, and all was well, so it is the ubuntu pre-release of 5.4.2 that's the issue.

So I'll try to tell the ubuntu people.  To be honest I find that really hard to raise a formal bug report.  They seem to put hurdles in the way of people raising faults, like asking for loads of dumps and stuff, so I emailed admin on the libreoffice packinging team a couple of days ago, referencing this report.  

I really do appreciate all the help here.

(In reply to Jean-Baptiste Faure from comment #1)
> Reproducible with Version: 5.4.3.0.0+
> Build ID: 3766aa5b3232beba4e4989696b6d19103ba0d62f
> Threads CPU : 4; OS : Linux 4.4; UI Render : par défaut; VCL : gtk3; 
> Ubuntu_16.04_x86-64
> Locale : fr-FR (fr_FR.UTF-8); Calc: single
> 
> set status to NEW

Isn't this a TDF-version? Ubuntu-Versions doesn't get such a long Build ID ...

(In reply to robert from comment #11)
> (In reply to Jean-Baptiste Faure from comment #1)
> > Reproducible with Version: 5.4.3.0.0+
> > Build ID: 3766aa5b3232beba4e4989696b6d19103ba0d62f
> > Threads CPU : 4; OS : Linux 4.4; UI Render : par défaut; VCL : gtk3; 
> > Ubuntu_16.04_x86-64
> > Locale : fr-FR (fr_FR.UTF-8); Calc: single
> > 
> > set status to NEW
> 
> Isn't this a TDF-version? Ubuntu-Versions doesn't get such a long Build ID
> ...
Looks like it.  I've not seen an ubuntu ppa containing 5.4.3, and as far as I know their build-ids always contain 'ubuntu' and an ubuntu version,

Hi Tim,

You tested against :

Build ID: 1:5.4.2~rc1-0ubuntu0.17.04.1

at least in your original comment. If that isn't an official Ubuntu release or a PPA, then where did it come from ?

Irrespective of the above, I note that both you and JBF have GTK3 builds, perhaps therein lies the problem ?

JBF, can we set this to CONFIRMED as you confirmed it with virtually the same VCL backend, albeit different Ubuntu OS and kernel versions ?

I can't reproduce this on my Linux Mint master build with GTK2 backend either.

(In reply to Alex Thurgood from comment #13)
> Hi Tim,
> 
> You tested against :
> 
> Build ID: 1:5.4.2~rc1-0ubuntu0.17.04.1
> 
> at least in your original comment. If that isn't an official Ubuntu release
> or a PPA, then where did it come from ?
> 
> Irrespective of the above, I note that both you and JBF have GTK3 builds,
> perhaps therein lies the problem ?
> 
> JBF, can we set this to CONFIRMED as you confirmed it with virtually the
> same VCL backend, albeit different Ubuntu OS and kernel versions ?
I was responding to the comment from robert@familiegrosskopf.de about the version tested by Jean-Baptiste Faure which did display the same fault:

Reproducible with Version: 5.4.3.0.0+
Build ID: 3766aa5b3232beba4e4989696b6d19103ba0d62f

See the 2nd comment.

(In reply to robert from comment #11)
> (In reply to Jean-Baptiste Faure from comment #1)
> > Reproducible with Version: 5.4.3.0.0+
> > Build ID: 3766aa5b3232beba4e4989696b6d19103ba0d62f
> > Threads CPU : 4; OS : Linux 4.4; UI Render : par défaut; VCL : gtk3; 
> > Ubuntu_16.04_x86-64
> > Locale : fr-FR (fr_FR.UTF-8); Calc: single
> > 
> > set status to NEW
> 
> Isn't this a TDF-version? Ubuntu-Versions doesn't get such a long Build ID
> ...

It is the current dev version of the 5.4 branch built at home under Ubuntu 16.04 x86-64. So if the problem is specific to Ubuntu, I think it must be searched in a library used by LO, for example gtk3, not in LO itself.
Will test again with my current 5.4 build.

Best regards. JBF

Created attachment 136720 [details]
how current LO 5.4.3.0.0+ opens the form

It seems to work as expected with my current build of 5.4 branch.

Best regards. JBF

So, to sum up, this problem seems present only in Ubuntu builds using the GTK3 backend, in which case, it is debateable whether this is a LibreOffice problem.

Normally, I would put this as NOTOURBUG, but...
we still have a lot of GTK3 problems referenced here with our own builds, so let's confirm, but change the title to reflect findings.

@Tim : there used to be some SAL_VCL_DISABLE_GTK3 instruction or something like that, that one could put into the .soffice script, or some other configuration file (I must admit, I haven't really followed that side of things), so that the VCL backend would revert back to a different default. If you could find that instruction, you might be able to test whether the behaviour is the same without the GTK3 backend.

Ah, a quick search on the interweb suggested using this in the shell before starting LibreOffice (from the shell) :

export SAL_USE_VCLPLUGIN=gen

Or, alternatively,

sudo apt-get remove libreoffice-gtk3

Hmm, and this useful nugget :

https://ask.libreoffice.org/en/question/3078/choose-gui-toolkit-for-lo-session/

These are only workarounds to the problem pending a fix to the GTK3 code. It seems like at least some of the default Linux builds are being compiled with GTK3 as the default VCL backend, and if this is the case, the problem will become more prevalent.

Thanks.

Having removed libreoffice-gtk3 (and ..-gnome) I'm now on Version: 5.4.2.2
Build ID: 1:5.4.2~rc2-0ubuntu0.17.04.1~lo1
CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: x11; 
Locale: en-GB (en_GB.UTF-8); Calc: group

The problem has gone away.

This may only be a short term fix since ubuntu is moving to gnome, and indeed I have been on gnome for some months.  I can't remember quite when and why I installed the gtk3 package after installing gtk3.  I think something else wasn't working well, but I don't recall what.  Time will tell :-)

Oops - That should have read "I can't remember quite when and why I installed the gtk3 package after installing ubuntu gnome"

And now I know why I installed the gtk3 component.  See #105857 - multi-select list boxes don't work on ubuntu without it.  I was running gtk2 at the time, and am now on gen (x11).

I'm rather caught between a rock and hard-place.

I would suspect that being a regression caused by

commit 159f55eab59d5a01973e5ea79f9109d25e5dac31
Author: Caolán McNamara <caolanm@redhat.com>
Date:   Sun Sep 10 16:07:49 2017 +0100

    gtk3: flicker-free opengl transitions
    
    leave the GtkGLArea opengl context alone except for the final render into it,
    create a new context for the slide transitions to play with
    
    set up a pair of framebuffers, a scratch one to let the transitions render
    into, the other to take a snapshot when the transition is finished with it and
    then tell GtkGLArea we're ready to render it and when the callback comes around
    copy the snapshot into it.
    
    Change-Id: I3515614baf7eea0ff53c46edbaf9cf66f926eef2
    
    hidpi+gtk3: move setting the opengl slide viewport
    
    to when the window size is set, and adjust to gtk3 hidpi
    scaling factor


https://gerrit.libreoffice.org/#/c/42143/
https://gerrit.libreoffice.org/#/c/42153/

https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-5-4-2&id=159f55eab59d5a01973e5ea79f9109d25e5dac31

Due to the problem I have at #113552 I now have to put up with these maximised screens. When opening several forms to have on display at the same time it's "a nuisance".

I might add that if libreoffice-gtk3 is installed, but I start libreoffice with 

SAL_USE_VCLPLUGIN=gen soffice

I still get maximised forms, even though the ubuntu version reports it is using VCL: x11;

I have now tried with libreoffice-gtk2, removing libreoffice-gtk3 and liberoffice-gnome.  The version is now:

Version: 5.4.3.2
Build ID: 1:5.4.3~rc2-0ubuntu0.17.10.1~lo1
CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: gtk2; 
Locale: en-GB (en_GB.UTF-8); Calc: group

I'm logging on as ubuntu xorg (not wayland or the separate gnome shell).

This resolves the form size issue (including on the test database attached), and I've not had any other issues yet.  

I'm a little surprised no one else seems to be having the same problem.

I've tried to bisect this issue but the win size is small in the latest commit of bibisect-linux-64-5.4 and it's large in the oldest commit of bibisect-linux64-6.0, so I guess it depends on the gtk3 version used to build LibreOffice...

I have the same version of ubuntu libreoffice (1:5.4.3~rc2-0ubuntu0.17.10.1~lo1) installed on my desktop and my laptop. 

My desktop is running full ubuntu(xorg) 17.10 which is based on gnome, and has the problem with the form sizing running libreoffice-gtk3.

Testing on my laptop, running xubuntu 17.10 (which is based on xfce) I don't have the problem with libreoffice-gtk3.

I tried LO 6.0.0.3, both directly from The Document Foundation, and from the ubuntu ppa.  

The problem still exists for gtk3 (both wayland and xorg).  I had to uninstall that and use gtk2.

Did you try to open the attached test database, open the form, resize it, save the database, close it, reopen and open the form again ?
Doing that with LO 6.0, the size of the form is retained for the next time the form is opened.

Best regards. JBF

With libreoffice-gtk3 and running:

Version: 6.0.1.1
Build ID: 1:6.0.1~rc1-0ubuntu0.17.10.1~lo1
CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: en-GB (en_GB.UTF-8); Calc: group

The sample database form still expands (after a brief smaller view) to fill most if not all of the screen, however much I try to edit the form size, save it and the database, close the database and re-open it.

Removing the gtk3 module seems to stop this behaviour.

I'm now on Version: 6.0.4.2
Build ID: 1:6.0.4~rc2-0ubuntu0.18.04.1
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk2; 
Locale: en-GB (en_GB.UTF-8); Calc: group

Whilst windows don't open full size every time with gtk2, they don't retain their size when last saved.  For a database application with many forms of differing sizes this is a real nuisance.  I seem to spend much of my time resizing forms.

Is there really no way to get Base on ubuntu to respect and remember the size of each form when edited and saved?

I'm puzzled as to why few others seem to have a similar issue.  Am I unusual in using Base as a platform (on ubuntu) to manipulate a relatively small but non-trivial database with around 35 different forms and 30 tables (with many relationships)?

(In reply to tim from comment #36)
> I'm now on Version: 6.0.4.2
> Build ID: 1:6.0.4~rc2-0ubuntu0.18.04.1
> CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk2; 
> Locale: en-GB (en_GB.UTF-8); Calc: group
> 
> Whilst windows don't open full size every time with gtk2, they don't retain
> their size when last saved.  For a database application with many forms of
> differing sizes this is a real nuisance.  I seem to spend much of my time
> resizing forms.
> 
> Is there really no way to get Base on ubuntu to respect and remember the
> size of each form when edited and saved?
> 

@Tim : do you see the same issue with LibreOffice provided releases.
From the above, it seems your problems are linked to distrib-specific provided builds (1:6.0.4~rc2-0ubuntu0.18.04.1).

From personal experience, I have never known an Ubuntu fresh release of LibreOffice not to contain additional bugs on top of those already known in the official TDF releases.

(In reply to Alex Thurgood from comment #37)
> (In reply to tim from comment #36)
> > I'm now on Version: 6.0.4.2
> > Build ID: 1:6.0.4~rc2-0ubuntu0.18.04.1
> > CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk2; 
> > Locale: en-GB (en_GB.UTF-8); Calc: group
> > 
> > Whilst windows don't open full size every time with gtk2, they don't retain
> > their size when last saved.  For a database application with many forms of
> > differing sizes this is a real nuisance.  I seem to spend much of my time
> > resizing forms.
> > 
> > Is there really no way to get Base on ubuntu to respect and remember the
> > size of each form when edited and saved?
> > 
> 
> @Tim : do you see the same issue with LibreOffice provided releases.
> From the above, it seems your problems are linked to distrib-specific
> provided builds (1:6.0.4~rc2-0ubuntu0.18.04.1).
> 
> From personal experience, I have never known an Ubuntu fresh release of
> LibreOffice not to contain additional bugs on top of those already known in
> the official TDF releases.

@Alex - Thanks.
Nothing has changed for many releases. I've just tried:

Version: 6.0.5.2
Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk2; 
Locale: en-GB (en_GB.UTF-8); Calc: group

and get similar problems.  Sometimes if I reshape one form, other forms take on the same shape.  The main form always seems to open full screen.

I tried a clean user profile to no effect.

I'm not sure why the version I downloaded from LibreOffice is running as tk2.

(In reply to Alex Thurgood from comment #37)
> (In reply to tim from comment #36)
> > I'm now on Version: 6.0.4.2
> > Build ID: 1:6.0.4~rc2-0ubuntu0.18.04.1
> > CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk2; 
> > Locale: en-GB (en_GB.UTF-8); Calc: group
> > 
> > Whilst windows don't open full size every time with gtk2, they don't retain
> > their size when last saved.  For a database application with many forms of
> > differing sizes this is a real nuisance.  I seem to spend much of my time
> > resizing forms.
> > 
> > Is there really no way to get Base on ubuntu to respect and remember the
> > size of each form when edited and saved?
> > 
> 
> @Tim : do you see the same issue with LibreOffice provided releases.
> From the above, it seems your problems are linked to distrib-specific
> provided builds (1:6.0.4~rc2-0ubuntu0.18.04.1).
> 
> From personal experience, I have never known an Ubuntu fresh release of
> LibreOffice not to contain additional bugs on top of those already known in
> the official TDF releases.

@Alex - Thanks.
Nothing has changed for many releases. I've just tried:

Version: 6.0.5.2
Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk2; 
Locale: en-GB (en_GB.UTF-8); Calc: group

and get similar problems.  Sometimes if I reshape one form, other forms take on the same shape.  The main form always seems to open full screen.

I tried a clean user profile to no effect.

I'm not sure why the version I downloaded from LibreOffice is running as gtk2.

With apologies for banging on about this once in a while.

Is it a fact of life that there are no options that will allow me to save each form at an appropriate size and keep each form at that size?  The lack drives me regularly crazy, particularly when doing a lot of work (as today to make changes to many of my forms for another issue).

Once upon a time this was possible, but it seems no longer, whatever gtk option I choose (on ubuntu 18.04) - they are all unsatisfactory in one way or another.

This applies to the generic versions of libreoffice as well as those from the ubuntu ppa.

I sometimes wonder if I'm almost the only person regularly using Base, but I guess I'm just too picky. :-)

(In reply to tim from comment #40)
> With apologies for banging on about this once in a while.
> 
> Is it a fact of life that there are no options that will allow me to save
> each form at an appropriate size and keep each form at that size?  The lack
> drives me regularly crazy, particularly when doing a lot of work (as today
> to make changes to many of my forms for another issue).
> 
> Once upon a time this was possible, but it seems no longer, whatever gtk
> option I choose (on ubuntu 18.04) - they are all unsatisfactory in one way
> or another.
> 
> This applies to the generic versions of libreoffice as well as those from
> the ubuntu ppa.
> 
> I sometimes wonder if I'm almost the only person regularly using Base, but I
> guess I'm just too picky. :-)
I just tried with Windows 10 (which I just keep as a backup OS) and it's much the same.  Reduce the size of some really small forms to be able to open in a corner of the screen, and all other forms then open small.

You could use the following workaround, started by a macro in every form:
SUB Window64
oFrame = StarDesktop.getCurrentFrame()
oWin = oFrame.getContainerWindow()
oWin.setPosSize(0,0,600,400,15)
END SUB

First value: x-start (Flag=1)
Second value: y-start (Flag=2)
Third value: width (Flag=4)
Fourth value: height (Flag=8)
Fifth value: Flag for all 1+2+4+8 = 15

You could also set
oWin.IsMaximized = true
That seems to be the behaviour you get if I understand the bug-report right.

(In reply to robert from comment #42)
> You could use the following workaround, started by a macro in every form:
> SUB Window64
> oFrame = StarDesktop.getCurrentFrame()
> oWin = oFrame.getContainerWindow()
> oWin.setPosSize(0,0,600,400,15)
> END SUB
> 
> First value: x-start (Flag=1)
> Second value: y-start (Flag=2)
> Third value: width (Flag=4)
> Fourth value: height (Flag=8)
> Fifth value: Flag for all 1+2+4+8 = 15
> 
> You could also set
> oWin.IsMaximized = true
> That seems to be the behaviour you get if I understand the bug-report right.
I'm not sure I understand the function (what's a "flag for all"?), but I can look that up, so thanks for that.

This report has morphed a bit.  It used to be able gtk3 maximising forms.  I then tried gtk2, and no gtk at all, but never got what I need, which is to revert to the behaviou several moons ago whereby one could:

1. Edit a form
2. Resize it and save it
3. Every time the form is opened it is at the saved size

Working out the size in pixels, and then recalculating for different screens, will be non-trivial for many tens of forms.  Resizing using a cursor is an awful lot easier, and is what I used to do.  

Still, at least this method is potentially do-able.

Apologies for the typos.

(In reply to robert from comment #42)
> You could use the following workaround, started by a macro in every form:
> SUB Window64
> oFrame = StarDesktop.getCurrentFrame()
> oWin = oFrame.getContainerWindow()
> oWin.setPosSize(0,0,600,400,15)
> END SUB
> 
> First value: x-start (Flag=1)
> Second value: y-start (Flag=2)
> Third value: width (Flag=4)
> Fourth value: height (Flag=8)
> Fifth value: Flag for all 1+2+4+8 = 15
> 
> You could also set
> oWin.IsMaximized = true
> That seems to be the behaviour you get if I understand the bug-report right.
Thanks for this.  I've managed to work this into my set of macros so that I set the size and position of the form I use most, which is a great help.

Except, with ubuntu 18.04 gtk3 the setPosSize behaves very badly.  Most settings of position simply don't work.  With gtk2, they usually work, except that, very strangely, only every other time a form is opened.  This is bizarre, to say the least, and I didn't beleive it either.  So I removed gtk2 as well, and ran plain:

Version: 6.1.3.1
Build ID: 1:6.1.3~rc1-0ubuntu0.18.04.1
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: x11; 
Locale: en-GB (en_GB.UTF-8); Calc: group threaded

and it all works every time.   

I thought these gtk oddities would be ubuntu issues, but 6.1.4 from Libreoffice has the same problems (it uses gtk2 by default).  The position is often wrong, and sometimes the setPosSize is just ignored.

Same bug with
Version: 6.0.7.3
Build ID: 1:6.0.7-0ubuntu0.18.04.2
Threads CPU : 4; OS : Linux 4.15; UI Render : par défaut; VCL: gtk3; 
Locale : fr-FR (fr_FR.UTF-8); Calc: group

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

I still have this problem on 6.4.4.2.

I can run without gtk3 (and gtk2), which reverts to x11, and the form sizes work OK.  But when I do that my multi-selection drop-down boxes don't work (the contents are not displayed).

Having tried generic (non-ubuntu-specific) builds in the past and having the same problem, I'm still somewhat stuck.  I can selectively get round it by having different desktops to start Base for different purposes, some using:

Exec=env SAL_USE_VCLPLUGIN=gen soffice --base --nologo -o .... 

to get properly sized forms


and some omitting the env clause so as to get gtk3 and hence multi-select drop-downs.

But it would be good if someone could sort out libreoffice with gtk3.  There are other issues, like setpos still not working properly (#120620).

I now remember why I moved back to gtk3.  On 6.4.4.2 on ubuntu 20.04 data entry from the keyboard does not work with X11.  NO data can be entered.  Items can be selected by mouse.

Bother.  So I am now stuck with wrong-sized windows.

Things moved on a while ago.  I'm now on 7.2.2.2-0ubuntu0.21.10.1

I reverted to VCL: x11 (data entry now OK), so I can size and position my key database forms in macros.  It's a nuisance, but that's life.

If I go back to gtk3, the SETPOS doesn't work properly on my database forms.  See #120620.

OK in Version: 7.3.7.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.3
Calc: threaded

And yes, I do have gtk3 installed.

I still have the setpos probem (#120620), but that's another isssue.