Created attachment 159157 [details] Example file from Word A date picker content control, if placed in a table, loses the first placeholder character when opened in Writer. The placeholder text is replaced when selecting a date, but the first character of the text stays in the document just before the control. This happens only if the control is in a table, not if it is in the document body. Steps to reproduce: 1. Open attached document in Word and Writer 2. Select a date from the controls in the document body and in the table. Actual results: In Writer the first character of the placeholder text stays in the table cell. Expected results: All of the placeholder text disappears. LibreOffice details: Version: 7.0.0.0.alpha0+ (x64) Build ID: bc898e2c2784e36ad4d4cdf6d962e39069d2c82d CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; Locale: hu-HU (hu_HU); UI-Language: en-US Calc: CL Also happens in: Verzió: 6.4.0.3 (x86) Build az.: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8 CPU szálak: 4; OS: Windows 6.3 Build 9600; Felületmegjelenítés: alapértelmezett; VCL: win; Területi beállítások: hu-HU (hu_HU); Felület nyelve: hu-HU Calc: CL But not in earlier versions, in 6.2-6.3 these became plain text, in 6.1 and before it was imported as date field UNO control, different from the date picker now. Bibisected using bibisect-win64-6.4 to: URL: https://cgit.freedesktop.org/libreoffice/core/commit/?id=68e1be4ccbb90ee9a788962219a88312c4ffbea2 author Tamás Zolnai <tamas.zolnai@collabora.com> 2019-07-10 18:22:31 +0200 committer Tamás Zolnai <tamas.zolnai@collabora.com> 2019-07-12 12:55:40 +0200 summary: MSForms: Rework text-based date form field's representation Adding CC to: Tamás Zolnai
Created attachment 159158 [details] Screenshot of the original document side by side in Word and Writer, after picking some dates
Thank you for reporting the bug. I can confirm the bug present in Version: 6.4.0.0.alpha1+ (x86) Build ID: ec7374ff84c71edfbb30d6e4dc5b486b6df7107f CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-11-10_21:37:30 Locale: en-US (en_US); UI-Language: en-US Calc: threaded
Dear NISZ LibreOffice Team, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still a problem in: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 9c796266470183f673eb58a8637dfe621eefa8b3 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded
Opening this from master I get an assert: 19a559b0ec9b8 (Michael Stahl 2019-10-14 16:55:50 +0200 1064) assert(!"this is presumably dead code");
Repro 7.5 master with Date entry-example.docx for the first in-table date, which is a BlockSdt (i.e. the paragraph is inside the contents as opposed to a RunSdt which is inside a paragraph). The second in-table date (which is a RunSdt) was fixed in LO 7.4 with commit 5ee8670f18cb8b1913a23d04590d6a31ac9730de Author: Miklos Vajna on Mon May 30 09:00:25 2022 +0200 sw content controls, date: add DOCX import
Czeber László Ádám committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fd79c5ed9b13516bdb0f2a29806296698ddda7b2 tdf#131722 DOCX import: fix lost first character in date selector It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
You can mark as Resolved Everything fine with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b88d11ba05085002cf847d4828ded52a3dfb3b09 CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded Bad in Version: 7.3.7.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.2 Calc: threaded
Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b88d11ba05085002cf847d4828ded52a3dfb3b09 CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Czeber László Ádám committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/855a14d4ca43b517884046eec7e7c75f44a9e975 tdf#131722 DOCX import: fix lost first character in date selector It will be available in 7.5.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3974c4748b9a2bcd054e0b9f9e3d42bdca45bef2 tdf#138093 tdf#131722 docx import: sdt lost first date character #2 It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/66700b8069715e42dd5f127a0daecabca5c6c0a8 tdf#138093 tdf#131722 docx import: sdt lost first date character #2 It will be available in 24.8.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.