Created attachment 122515 [details] Table listing Summary Footer NOT SHOWN Using LibreOffice version 5.1.0.3 on Mac OSX 10.11.3, the record summary FOOTER is not visible when a Base TABLE LISTING window is first opened (from the TABLE PANE list). If the window is resized, the footer is re-drawn and is then visible as normal. See the attached screenshot. The problem looks like a window rendering bug.
So by TABLE LISTING you mean simply clicking open a Table? I tried with an existing file, but don't know how to display some text in the footer, so cannot confirm. Please attach an example file where we can see the effect. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the document.
Created attachment 122595 [details] table summary footer as NORMALLY SHOWN
"So by TABLE LISTING you mean simply clicking open a Table?"... Yes, I mean clicking open a table. "I tried with an existing file, but don't know how to display some text in the footer, so cannot confirm." The 'normal' (default) behaviour is that the footer area should ALWAYS shows the words... 'Record X of N...' followed by the usual navigation controls on the right. See the attached screenshot to show how it should look when the table list window is first opened. NOTE: It does not matter which file/table I open, the result is always the buggy behaviour (as shown by the first screenshot I attached). I don't have any suitable/public Base files I can supply right now, but the buggy behaviour should be visible in any Base document you open (at least on a Mac). Let me know if you really do need a sample Base file and I will create one and attach.
Ah, it seems I was too confused by the bug :) I can confirm that there is a white rectangle over the summary. Resize makes it go away. I confirm the problem is not present in 4.4. Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: a6f876d45bd4e41a7143594a6cb11b6893a0f620 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-02-11_00:07:38 Locale: fi-FI (fi_FI) Version: 4.4.5.2 Build ID: a22f674fd25a3b6f45bdebf25400ed2adff0ff99 Locale: fi_FI
*** Bug 97855 has been marked as a duplicate of this bug. ***
ef8163604f7946ba35b5d133cf6e7a41c750a112 is the first bad commit commit ef8163604f7946ba35b5d133cf6e7a41c750a112 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Thu Nov 12 21:07:25 2015 -0800 source f02ae7a1bba0a061b8d6d0fef1155bdd9feb16e3 source f02ae7a1bba0a061b8d6d0fef1155bdd9feb16e3 source d01a81338abe84491684b9f3925ba98c43163fe7 source e08fbe4c592b25fb88828157ff054431ac8e2d8b source 2d0341a23f95e322990006d78d3f514a9448ed84 source e660a0515889ce42e95c57af8c3815a1afc2f1dc source 2d30f347ccdc4539a695f04d91a3706d02a857e1 source e9fcefe4640dfa0895dca703a37f27ea5b2e893c source 14e409188b2068e04c63201803039b250113ae37 source ce6eed613cb2bd79a66cf9c10e3370fcb4949c6d source 9f90d987901f9f69e78370705a7f000f5d7d4902 source 2dbe457fbcd99ea09e5a97b39e216e575c260cbe source a201f0cc675ea5b5b1ef71d6cef7ea7ef4e74923 source 8557a8a74dc692ef7ec83d95413ddc3186aa0695 source d7627da5c9b0b351e8150b08febf64273ba0231e source c4ef30ea916752ba5a057b49960a60a55f70c84c source bb34de0189a7c2ac81c08f3a283a71c2e67093d3 source 11fc639c0897a192f1da0c69d1f7ab683ff1208e source 52e08f200e5ed525cb1ff92a13ab85d36cd7459f source fd8c98861c94dfa572253b53809c49bbd975dfc0 source d6c82fe72787702c9c90ff890b86519604a4273c source e7ab3554f53df02088451361a154e4574494a8f7 source 8bae6345bff0508f5f01e0061d7b576f36e6961d source 54c679af63b87dd83b6da07201b68728bded4ba9 source 0c7913de2f0b91de623838dfd4013c5e92bad6d8 source 4bdf05b28d6584a1986ac7e5855d0260ff62930d source 32686b0d0a15a653f831d0645e5b7c1145860570 source c65e00d908a2dcf47d3ff925d09e336d9b0939f7 source 899453aa8407fca8a93d51f12ad4e335d1beeb62 source 6128c10f550924c2b75f18b6c6220cc1770adba4 source 2b4d7be9484d360d8361dd71d767afbcc67fdcb2 source a133053f94f7c5b05f4354bb4977c2250b470a8a source 737555eb2ff5f4f90b9794784e1ac8f0451b9b97 source 5c142dd31de4a6d1c6ce9885ad06d84aca492152 source 266abd09fd2d449351e356bc48f65c725b121247 source b92174e4c723bacfcfc245a483365cc7fb5d72c1 source c504477e7c3c7109fc4439988d8f3eb11a267c74 source 44daaebf835bb60fb7e442e928cd30191f15af52 source a7816853bad55ada597092c16ba9a0a761e067d0 source 14c2b509928b7c7a437464c10bd0f57ff307ad54 source fa91dd31f39a24329d288d4e1cda28db3a16af0d source c21ddcdb30b8dd7be56176e00bc2d4780cb342e1 source a31b4f4c6eaa7a2e5e5986a4dee5acbd94ada8d1 source 3503873c7b54c013e7cfe8f73ce8485862348592 source 1bea36ddadae18a66d2e6043681b5b6fa37e4da1 source 12bf19b8e6cff6309f70675ebaaeb7b356b1967b source 2ff2fafff8fe455a2493d04e7da709588a691ddd source 0521461eee932eefbd69fcd39407f181bc2213dd source 8978ce53e16de9a597015b0704f813dffa7da920 source 44d3577f4b5ec181219268826d2ec504e61541f3 :040000 040000 1ce755f5622de2e074a52f040a4cbce581150fae 09ea88eeec0c2980170abeadabf9920e658174ab M instdir
*** Bug 98428 has been marked as a duplicate of this bug. ***
*** Bug 98547 has been marked as a duplicate of this bug. ***
*** Bug 98577 has been marked as a duplicate of this bug. ***
This bug is still present on LO v.5.1.1.3 (Mac OSX). As it is clearly a recent and very 'visible' regression with the potential to cause considerable inconvenience to most Base users (since, to see the record count and navigation controls, they have to re-size the table listing window every time a table is opened), I am escalating importance to MEDIUM NORMAL (from MINOR).
(In reply to frofa from comment #10) > This bug is still present on LO v.5.1.1.3 (Mac OSX). As it is clearly a > recent and very 'visible' regression with the potential to cause > considerable inconvenience to most Base users (since, to see the record > count and navigation controls, they have to re-size the table listing window > every time a table is opened), I am escalating importance to MEDIUM NORMAL > (from MINOR). Please give reasoning of escalation according to this flowchart: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
In reply to comment 11 from Buovjaga: The Bug Priority Triage Flowchart Suggestions(s) diagram does in fact say regarding REGRESSIONS: "Special attention should be made to prioritizing regressions. Usually a regression calls for increased priority unless there is a specific reason not to raise it, in which case a comment in the bug is probably a good idea." As I stated earlier (comment 10), this bug is: 1. A very recent regression 2. The loss-of-function has the potential to significantly inconvenience many Base users. As there have been a number of quite recent regressions in Base, it sometimes seems to be me (as committed and enthusiastic Base user for many years) that the overall functionality of the Base module is going backwards of late. I reckon one could pretty convincingly argue that Base in LO 4.7.x works better than in LO v5.x in a number of ways. (Sorry to be negative because I know the volunteers put in a lot of otherwise good work.)
Priority can be higher, but severity is about how bad the bug actually is. So a regression can be "minor" severity, but "high" priority, if it is not that bad in its effects, but highly visible nonetheless.
I guess this question (comment) flows on in this thread - but is there a flowchart or some other PROCESS DESCRIPTION of how BUG FIXES are tested BEFORE they are actually incorporated in the LO software? I assume there is, but I cannot find it. It seems to me that quite a few so-called REGRESSIONS are 'introduced' as a result of other bug fixes. Is there any info on this? (Just interested).
(In reply to frofa from comment #14) > I guess this question (comment) flows on in this thread - but is there a > flowchart or some other PROCESS DESCRIPTION of how BUG FIXES are tested > BEFORE they are actually incorporated in the LO software? I assume there is, > but I cannot find it. It seems to me that quite a few so-called REGRESSIONS > are 'introduced' as a result of other bug fixes. Is there any info on this? > (Just interested). There is no such document. Automated testing is running continuously on servers. Increasing unit test coverage is the one way to automatically catch regressions. There is also a crash testing virtual machine running automated tests.
LibreOfficeDev_5.2.0.0.alpha1_Win_x64 still has the problem
we have three additional confirmations of the bug on: OpenSUSE Leap 42.1 64bit rpm Linux, LO 5.1.3.1 LO 5.1.1.3, Windows 10, 64 Bit LO 5.1.2 Win 8.1 64Bit
*** Bug 99814 has been marked as a duplicate of this bug. ***
Confirmation also for Version: 5.1.3.2 Win 7 Pro 64-bit Version: Build-ID: 644e4637d1d8544fd9f56425bd6cec110e49301b CPU-Threads: 8; BS-Version: Windows 6.1; UI-Render: Standard; Gebietsschema: de-DE (de_DE) Thanks to all who work/track on this issue, it effects end users when using a deployed Base application without having knowledge about working with the Module Base.
(In reply to riesslibo from comment #19) > Confirmation also for > > Version: 5.1.3.2 > Win 7 Pro 64-bit Version: > Build-ID: 644e4637d1d8544fd9f56425bd6cec110e49301b > CPU-Threads: 8; BS-Version: Windows 6.1; UI-Render: Standard; > Gebietsschema: de-DE (de_DE) > > Thanks to all who work/track on this issue, it effects end users > when using a deployed Base application without having knowledge about > working with the Module Base. For a normal user is it a useful knowledge to know how to walk through bugs ? He has better to know !
On my builds of versions 5.1.4.0.0+ and master under Ubuntu 16.04 x86-64 it is enough to resize the window to make the navigator bar visible again. Best regards. JBF
Always in Version: 5.2.0.1.0+ Build ID: 91f2f71e7b936c3c9fb984aaa01d432926abb38f It is a very annoying bug when there is number of users who do not know how to avoid this blank bar. Much time lost by users and support.
Is there no projected fix for this issue? I am still running version 5.0 because this bug, which is in both 5.1 and 5.2, is so annoying, but so is the reminder that keeps popping up reminding me to upgrade to the latest version.
I personally wish the importance of the bug could be elevated, in hopes that it will get fixed soon. It is so annoying (since I work with Base tables often) that I have to just stick with version 5.0, which doesn't have this bug. Every time I see a new version become available, I look eagerly to see whether this bug was fixed, but alas, not yet...
(In reply to David Burleigh from comment #24) > I personally wish the importance of the bug could be elevated, in hopes that > it will get fixed soon. That won't help, but what will is that you figure out a way to recruit more Base developers.
*** Bug 101015 has been marked as a duplicate of this bug. ***
Version 5.1.4.2.(x64) on Windows 10 64bit Build ID: f99d75f39f1c57ebdd7ffc5f42867c12031db97a still has the problem. As royerjy says, not all end-users are capable of understanding workround.
Confirming this annoying bug is still present in LO version 5.2.1.2 on Mac OS 10.11.6 'El Cap'. Does the bibisection result indicate the source of the problem?
Still presents in 5.2.3RC3. What a pity !
This bug is still present in 5.3.0.0.beta1
*** Bug 105482 has been marked as a duplicate of this bug. ***
Created attachment 130645 [details] Build ID & table view I have also seen this problem for some time but found something different. I have source for v5.3 and updated it on 1/22/2017 then re-compiled. The problem is not present. I do see the problem in v5.2.3.3 and a daily from 12/29/2016. Linux Mint 18.
Stang, I could see the bug in 5.3.0.3 / Windows 7. Caolán, could the following commit from the range in bibisect results in comment 6 be related to this bug? "Resolves: tdf#95723 arrange GridControl buttons to be always visible" https://cgit.freedesktop.org/libreoffice/core/commit/?id=44daaebf835bb60fb7e442e928cd30191f15af52
possibly, I can definitely fix it anyway
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=917d5b8b26a7428f7b7dd495a8db14a3ce16aa55 Resolves: tdf#97731 allow status bar to adapt to its own preferred size It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
backport in gerrit for 5-3
How does one get and apply the patch to version 5.3?
David, the fix will be available in an upcoming 5.3 bugfix release, possibly in 5.3.2.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=95eff15aa6e02ab875bd898f6be4f23343ba6b9b&h=libreoffice-5-3 Resolves: tdf#97731 allow status bar to adapt to its own preferred size It will be available in 5.3.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Fixed in 5.3.2.2 (x64) thank you