The problem occurs when in Table Data View or a grid on a form. It only happens on columns containing numeric data. Text columns are not affected. When viewing a table (or a grid), select any cell in a numeric column. Using arrow down key, proceed all the way down to a new record. Now use the arrow up key once. Data in the cell cannot be seen or edited at this time. Arrow left or right produce the same results in any numeric cell. Text cells are unaffected, but arrow left or right back to a numeric cell and the data is not visible. Arrow UP one more and the problem goes away. The same happens using a mouse. Double left click on new record line in a numeric column then arrow up or left mouse click on cell above. The problem only affects the last row of data and corrects itself once any other row is selected. I also saw this same problem in v4.4.5.2 but not in v4.2.8.x
This is similar, if not identical, to bug 92275
@Stang: it might be worth trying a recent daily/nightly build to see if the fix for bug 92275 has also fixed this behaviour/
OK I downloaded Version: 5.0.2.0.0+ Build ID: aff9057c35827ec7a6219b1c752f7525db64cdca TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-5-0, Time: 2015-08-13_06:15:07 Locale: en-US (en_US.UTF-8) First I must correct my original post. Data is affected for ALL rows and ALL numeric fields until a refresh is done. The daily build had no change on the problem.
(In reply to Alex Thurgood from comment #2) > @Stang: it might be worth trying a recent daily/nightly build to see if the > fix for bug 92275 has also fixed this behaviour/ Nope wrong reference, sigh, sorry about the noise
Confirming on Version: 5.1.0.0.alpha1+ Build ID: ea29d320754fdb21b336cb78f816b8081371def9 Locale: fr-FR (fr.UTF-8) OSX 10.10.4
Problem not present in Version: 4.1.4.2 Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72 ==>> regression
Problem also not present in Version: 4.3.5.2 Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5
No problem in Version: 4.4.3.2 Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16 Locale: fr_
I don't see the problem in 4452 either, I only first see it from Version: 5.0.0.4 Build ID: cf112dc905650fb985306a7a03d2fe3fcc6c978f Locale: fr-FR (fr.UTF-8) onwards.
This seems to have begun at the below commit. I see Lionel is already Cc:'d; Could you possibly take a look at this one? Thanks commit 3b9e66fdcade5a222a9dc99ad74627473b1fd4e7 Author: Lionel Elie Mamane <lionel@mamane.lu> Date: Wed Jul 22 16:25:28 2015 +0200 tdf#92725 FormattedField: when model value is NULL, force empty display string as opposed to implicitly keeping whatever unrelated string was there before. Change-Id: Ifaf1b41e951e97f209ecb617b32ec4f7522b1d08 :040000 040000 26763db78dab66ce561b8ac290c7206b4dcff574 1bd2d7f0efcd7aeb3d447053e3c13d9e66a0a86b M svx
I confirm Matthew's notice. If you revert the patch, numbers appear. Perhaps translation of German comments in DbFormattedField::GetFormatText may help (see http://opengrok.libreoffice.org/xref/core/svx/source/fmcomp/gridcell.cxx#1486). I must recognize I'm lost even with Google translate. I spent some hours to understand which part is called but gdb fails (once you get a bt, if segfaults and LO keeps on to run!). I don't even get the role distribution between svx/source/fmcomp and svx/source/form
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=eb33ef931a635d2d706e2ec4abec3f5a7a24674a tdf#93390 correctly handle back-and-forth between numeric and text value It will be available in 5.1.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.
*** Bug 93618 has been marked as a duplicate of this bug. ***
In order to allow backport to libreoffice-5-0 branch (to put the fix in LibreOffice 5.0.4), we would need a confirmation that the commit fixes the bug. Could someone please test a nightly, or cherry-pick the commit to their local build, and see that the bug is fixed? Then please say that on https://gerrit.libreoffice.org/19372 or here. Thanks in advance.
Created attachment 119786 [details] sample table
Created attachment 119787 [details] test sample
I have just tested this using: http://dev-builds.libreoffice.org/daily/libreoffice-5-0/Linux-rpm_deb-x86_64@46-TDF/2015-10-20_10.11.08/libreoffice-5-0~2015-10-20_10.11.08_LibreOfficeDev_5.0.4.0.0_Linux_x86-64_deb.tar.gz The problem still exists. Data only disappears when going from a numeric field to a new record & back to a numeric field. This was and still is the original problem.
Stang, you need to test with a daily of 5.1 (master), not of 5.0 See for example http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF/current/
Version: 5.1.0.0.alpha1+ Build ID: e58f9cad29404670085803a8010729a735759088 Locale : fr-FR (fr.UTF-8) OSX 10.11 Tested with test sample file attached in bug report - works, so set to verified fixed
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=43769b7aebd6e89c5d9260b244e34d0858e99216&h=libreoffice-5-0 tdf#93390 correctly handle back-and-forth between numeric and text value It will be available in 5.0.4. 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.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-5-0-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d715f2249e827716ed7a7b88035c78e62540d2e2&h=libreoffice-5-0-3 tdf#93390 correctly handle back-and-forth between numeric and text value It will be available in 5.0.3. 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.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]