Description: Viewing problem for the table of odb file with embedded data. The fields with Memo [LONGVARCHAR] format appear darkened. The data is still visible by clicking in the cell. The bug does not affect the fields with different formats like Integer or Text for instance. Bug not present in LibreOffice 7.0.4. Steps to Reproduce: 1.Open ode file with embedded data and at least one field with Memo [LONGVARCHAR] format 2.Select Tables 3.Open the table containing the data Actual Results: All the fields with Memo [LONGVARCHAR] format appear darkened. The data is still visible by clicking in the cell. The bug does not affect the fields with different formats like Integer or Text for instance. Expected Results: Column should not be darkened, data should be visible with no need to click on a cell to see what it contains. Reproducible: Always User Profile Reset: No Additional Info: See pictures attached: one showing the viewing problem, one detailing the structure of the table.
Created attachment 170296 [details] Table - data with darkened columns for Memo [LONGVARCHAR]
Created attachment 170297 [details] Table structure
Could you give a try at https://wiki.documentfoundation.org/QA/FirstSteps? What embedded database do you use? Firebird or Hsqldb? On which MacOs version are you? Do you use a specific theme? Do you reproduce this on a brand new file with just 2 fields an id field for primary key + test memo field? Would it be possible you attach your file? Of course you must sanitize it (see https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission)
Created attachment 170311 [details] fresh simple database showing the problem As requested, this is a simple database created to show the problem. It is Hsqldb embedded data.
My computer is a 2013 macbook pro (intel), under macOS 10.15.7 Catalina.
I deleted my user profile to test if it helps, and I can confirm that it does not help with this issue. Also, I don't use any specific theme.
Thank you for your feedback. I can't reproduce this. Perhaps MacOs only? Anyway, since I can't help here=>uncc myself.
Bug still present in LibreOffice 7.1.2 RC1. Bug not present in LibreOffice 7.0.5, so I reverted to it while a fix is found. Let me know if I can be of further assistance. Thanks for your work.
For information, the bug is still present in the LibreOffice 7.1.2 release. I also checked and can confirm that the bug is present on another Macbookpro (under macOS X 10.11.6). I don't have a windows laptop to test.
Tested this with LO 7.1.2.2 on OpenSUSE 15.2 64bit rpm Linux. Couldn't find any darkened column when opening the table. So might be a special Mac bug.
Reproduced with Version: 7.1.2.2 / LibreOffice Community Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4 CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded sigh...
Bug not present in Version : 6.4.6.1 Build ID : 985dd72ca280d5c6da2e9f90f7ff9286cafe7ff8 Threads CPU : 8; OS : Mac OS X 10.16; UI Render : par défaut; VCL: osx; Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded
Just for information, bug present in LibreOffice 7.1.3 RC1.
I tested again LibreOffice 7.1.2.2 but after installing the new JAVA JDK 16.0.1 (I had version 16 before), and can confirm that it does not change the situation. The bug is still present. Just thought that it was good to give it a try. NB: If you are not familiar with LibreOffice on Mac, for as long as I recall, Mac users have had to install the JDK instead of the JRE, for Base to work as expected.
Just for information, bug still present in the released version LibreOffice 7.1.3.2.
I would be inclined to mark this as a duplicate of bug 125514
Bug 125514 was opened in May 2019 for a text rendering issue which occurred in an older version of LibreOffice (6.3), not affected by the bug of this thread. Apparently, the text rendering issue was fixed, so maybe bug 125514 should be closed. The confusion comes from the fact that May 26, 2021 comment #19 on bug 125514 pointed to what seems the same bug as this thread but it seems that it is not related to the initial reason of opening bug 125514.
Just for information, bug still present in the released version LibreOffice 7.1.4.2.
Just for information, bug still present in the released version LibreOffice 7.1.5.2.
The described problem is NOT present using LO version 7.0.6.2 on Mac OS 'Catalina' version 10.15.7 with the example database 'fresh simple database showing the problem' provided above.
Thank you frofa. The bug was discovered with the 7.1.1 version, and does not affect 7.0.x versions.
Just for information, bug still present in the released version LibreOffice 7.2.0
(In reply to Yannick Chiron from comment #22) > Just for information, bug still present in the released version LibreOffice > 7.2.0 Yep, confirming here too with Version: 7.2.0.4 / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded
You could try bisecting it with the 7.1 repository: https://wiki.documentfoundation.org/QA/Bibisect/macOS
(In reply to Buovjaga from comment #24) > You could try bisecting it with the 7.1 repository: > https://wiki.documentfoundation.org/QA/Bibisect/macOS I tried bisecting with the 7.1 repository but it was all good. Then I bisected with the 7.2 repository and found the following commit. 73381f7077e114b39dc2c46344d0366c7254de2e is the first bad commit commit 73381f7077e114b39dc2c46344d0366c7254de2e Author: libreoffice <libreoffice@libreoffices-Mac-mini.local> Date: Fri Mar 26 12:32:18 2021 +0100 source 1a167625314bf36b735176ed488e6ba9b5e9b675 source 1a167625314bf36b735176ed488e6ba9b5e9b675 .../Contents/Frameworks/libvclplug_osxlo.dylib | Bin 792028 -> 801996 bytes .../Contents/Resources/config/images_breeze.zip | Bin 1888042 -> 1888042 bytes .../Resources/config/images_breeze_dark.zip | Bin 1883715 -> 1883715 bytes .../Resources/config/images_breeze_dark_svg.zip | Bin 1566710 -> 1566710 bytes .../Resources/config/images_breeze_svg.zip | Bin 1564232 -> 1564232 bytes .../Contents/Resources/config/images_colibre.zip | Bin 2757318 -> 2757318 bytes .../Resources/config/images_colibre_svg.zip | Bin 2883054 -> 2883054 bytes .../Resources/config/images_elementary.zip | Bin 4174032 -> 4174032 bytes .../Resources/config/images_elementary_svg.zip | Bin 5454875 -> 5454875 bytes .../Resources/config/images_karasa_jaga.zip | Bin 4879773 -> 4879773 bytes .../Resources/config/images_karasa_jaga_svg.zip | Bin 19303300 -> 19303300 bytes .../Contents/Resources/config/images_sifr.zip | Bin 2104813 -> 2104813 bytes .../Contents/Resources/config/images_sifr_dark.zip | Bin 2106689 -> 2106689 bytes .../Resources/config/images_sifr_dark_svg.zip | Bin 1756382 -> 1756382 bytes .../Contents/Resources/config/images_sifr_svg.zip | Bin 1752511 -> 1752511 bytes .../Contents/Resources/config/images_sukapura.zip | Bin 3040207 -> 3040207 bytes .../Resources/config/images_sukapura_svg.zip | Bin 4345422 -> 4345422 bytes LibreOffice.app/Contents/Resources/setuprc | 2 +- LibreOffice.app/Contents/Resources/versionrc | 2 +- 19 files changed, 2 insertions(+), 2 deletions(-)
bisect log: # bad: [20651168152192ab9e0f9d12a94228b24125b0d4] source 3d311c6d63eafbe2f76d6f1768dc3f675970a55a # good: [7ae9dc0eb055b3d88573a247cf3f756b06ad5cad] source 738bcf5e9a8c443d60c29c3a8068e8c16c72638a git bisect start 'master' 'oldest' # bad: [de3791b1403f4e466497581e5a49f06f94701dbb] source 9279dce41152ed692c125edfed4c80a7c28c7a0b git bisect bad de3791b1403f4e466497581e5a49f06f94701dbb # good: [156360b0cc59e95e1deb3f2b63c8572b055ff9a0] source 022f61e6bd876fbcbcefd63708bf4c7ee5063f3a git bisect good 156360b0cc59e95e1deb3f2b63c8572b055ff9a0 # bad: [c97f1de0178ec9b8e314df9e5c43ceca2e6fbc1e] source 86b192965ee8d625092b723337f6a65bdf34dcb7 git bisect bad c97f1de0178ec9b8e314df9e5c43ceca2e6fbc1e # bad: [d3951b89e6b7f631114b3aa866378788fe7f8877] source 167f4edc54bca5f62f098dcff2bff3cce4a51c58 git bisect bad d3951b89e6b7f631114b3aa866378788fe7f8877 # bad: [bf887f5547accfd8513351000cdbd7620a92de2b] source 6220d619b42b18cca7280174daed56aad5c82fce git bisect bad bf887f5547accfd8513351000cdbd7620a92de2b # bad: [62add0f516fea5072693b8dcf9dc2e91075d5ee1] source 3b3591d3c127c306f4d5f6bbb34118b03c3124c0 git bisect bad 62add0f516fea5072693b8dcf9dc2e91075d5ee1 # good: [ced5ab4d71d13cfe543a164bfc5b0bc3805e13f3] source 602a044014b55a5a1b1a5f0e96af603590ee899f git bisect good ced5ab4d71d13cfe543a164bfc5b0bc3805e13f3 # bad: [b00c689af48d3f973d91e7a6c3212cd25e0ebbbf] source b6f574ad86316956cf27efec61af9cbda273e054 git bisect bad b00c689af48d3f973d91e7a6c3212cd25e0ebbbf # good: [8644b62f52c663eaa03691f3868eb56c53fa4600] source ad55d51486264260a135b36c85973a728e006de7 git bisect good 8644b62f52c663eaa03691f3868eb56c53fa4600 # good: [6553109660ff34893fed1fba2a54d2fdfed1faee] source 79e471dc116f0b662e48d915d395d398057d137f git bisect good 6553109660ff34893fed1fba2a54d2fdfed1faee # bad: [deab522b3aa90a43f9b3c703894e8a014b08b33f] source 058ad4b900b5e0ee902f3e89ed121c2b5f8c58f1 git bisect bad deab522b3aa90a43f9b3c703894e8a014b08b33f # bad: [73381f7077e114b39dc2c46344d0366c7254de2e] source 1a167625314bf36b735176ed488e6ba9b5e9b675 git bisect bad 73381f7077e114b39dc2c46344d0366c7254de2e # good: [2538fbd480d71ad492642b8b02792cbdeda42a29] source 5bd90f7f5852056342f1a81a1285b474d468eadd git bisect good 2538fbd480d71ad492642b8b02792cbdeda42a29 # first bad commit: [73381f7077e114b39dc2c46344d0366c7254de2e] source 1a167625314bf36b735176ed488e6ba9b5e9b675
I would add to this that it isn't just the content of MEMO fields as defined in the DB that are displayed as black blocks, but any query that returns a string considered as LONGVARCHAR/MEMO. For example, using the Firebird LIST() function in a SELECT query returns a query display in which the data is blacked out in the Query result window.
(In reply to psidiumcode from comment #25) > (In reply to Buovjaga from comment #24) > > You could try bisecting it with the 7.1 repository: > > https://wiki.documentfoundation.org/QA/Bibisect/macOS > > I tried bisecting with the 7.1 repository but it was all good. > Then I bisected with the 7.2 repository and found the following commit. > > 73381f7077e114b39dc2c46344d0366c7254de2e is the first bad commit > commit 73381f7077e114b39dc2c46344d0366c7254de2e > Author: libreoffice <libreoffice@libreoffices-Mac-mini.local> > Date: Fri Mar 26 12:32:18 2021 +0100 > > source 1a167625314bf36b735176ed488e6ba9b5e9b675 > > source 1a167625314bf36b735176ed488e6ba9b5e9b675 I guess https://git.libreoffice.org/core/commit/1a167625314bf36b735176ed488e6ba9b5e9b675 tdf#138122 Add window scaling for retina displays on macOS ...is plausible as it touches rendering stuff. Adding Cc: to Thorsten Wagner
Having checked with following configuration: MacBookPro 13', 2015 LO 7.2.0.4 PostgreSQL 12 This bug occurs when a query/view column is defined as "text". Using "varchar" instead solve the problem (as a workaround, of course)
Thanks for this workaround. I can also confirm that replacing in the Table structure a field labeled "Memo [LONGVARCHAR]" by "Text [VARCHAR]" makes the text appear normally. But one must be aware that "Memo [LONGVARCHAR]" has an unspecified length of characters ("0" for unlimited) whereas "Text [VARCHAR]" has a 100 characters length by default (can be extended, I just tried 10,000 length). So overall, it seems that it is a working workaround while waiting for a fully satisfying fix.
Just for information, bug still present in the released version LibreOffice 7.2.1, and with the released Java openjdk-17 installed.
Bug still present in the released version LibreOffice 7.2.2.
Issue seems to have disappeared with current revision from master. Using the example database issue was reproducible with LO 7.1.7 and was no longer present with LO 7.3.0. As there were no changes within retina rendering stuff on macOS, this was probably not the root cause.
Issue no longer exists with LO 7.2.3 (see screenshot attached).
Created attachment 176389 [details] Screenshot using LO 7.2.3
Hello. I confirm that the issue is resolved with the released version LibreOffice 7.2.3. Thanks everyone.