Description: When a textbox is clicked the (empty) content of the box (spaces) is kept instead of replaced by the user entry. Steps to Reproduce: 1. Open file 2. Click in box Actual Results: The box is clicked and the cursor is placed on the position where it is placed. All the empty space is kept when a value is entered. Expected Results: When the box is clicked and content is typed/copied in, the existing space is removed and replaced by the entered value. Reproducible: Always User Profile Reset: No Additional Info: The easy workaround: Double click. This will select all space. Yet Word does in a single click what LibreOffice needs to clicks to complete the same task. Version: 7.3.4.2 / LibreOffice Community Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5 CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: de-AT (de_AT.UTF-8); UI: de-DE Flatpak Calc: threaded
Created attachment 181299 [details] docx file An actual report form that is used at my workplace but the content was replaced to avoid sharing data that might be confidential. The important box for this report are the text boxes like they can be found on the second page. To recreate the report just click in one of the text boxes. The cursor is placed where you clicked. The space is not removed when you type.
So the request seems to be: upon a click or keyboard navigation into a field, its contents should be pre-selected? I have tested the attachment using MS Word 2016, and indeed, that is how it works there. Also the pre-existing content of the fields looks "special": not only it gets pre-selected: you can't also select part of it to e.g. append; this is different to what happens after you typed something into a field: when you later move into such an edited field, it gets pre-selected at first, but pressing an arrow (left or right) second time turns the selection into a normal cursor that can travel inside the previously typed text. In LibreOffice Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 14553d280ad76c3436d394e900002c63de7b6e51 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL it behaves as the report describes. Miklos: do you have an opinion on this?
I think e.g. our ask field already does this. Then content controls do this in Word conditionally: if the content control is showing its placeholder, then the content is pre-selected, but not otherwise. In any case: if there is a request for it, then moving the Writer UI closer to Word sounds good in general.
Confirming in Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 8475b367298de73aec6abc60a159cc015baf9734 CPU threads: 14; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: threaded Also changing title to reflect the need for behavior change.
(In reply to Mike Kaganski from comment #2) > So the request seems to be: upon a click or keyboard navigation into a > field, its contents should be pre-selected? This is very similar to how LO implements content controls with placeholder text as mentioned in comment 3. However, it doesn't appear that we currently keep track of "default text" or not in the case of these legacy formfields. See https://gerrit.libreoffice.org/c/core/+/142646 as a code pointer, which attempts this for tracking the default status of a checkbox. Commit 06ff1602842197f045f953fd49e441f8f058d094 could be a useful code-pointer relating to how content-controls decide whether to select the field or not. Likely similar formfield code is nearby.
Oliver Specht committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/96323a10d3a55d212c350886e2a1344c0cd2ba95 tdf#150037 Writer: text fieldmark behaviour changed It will be available in 24.8.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.
Verified in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f5a8d01d381925bba6a2560aacf5ca159fc0bdea CPU threads: 15; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: threaded Now a single click selects the whole default text, which has the space-degree sign placeholder. Typing replaces the whole default. The typed text can be edited if the cursor is moved inside the field. Only difference I see is that in Word a single click highlights only the whole field if it has the placeholder, in Writer a single click highlights it after typing custom text as well.
(In reply to Gabor Kelemen (allotropia) from comment #7) > Only difference I see is that in Word a single click highlights only the > whole field if it has the placeholder, in Writer a single click highlights > it after typing custom text as well. It is worse than that. The entire field is removed, which is NOT what this bug report was asking for. A single click selects the entire field now. A double click selects only the field's contents (which has always been true. TODO: The single click should also be selecting only the field's contents. As Gabor noted, the field contents should only be selected if they are marked as placeholder (default) content. Once custom text is entered, a click should not select anything. This patch has simply exchanged one undesirable trait with two undesirable traits. I suggest it be reverted.
(In reply to Justin L from comment #8) > This patch has simply exchanged one undesirable trait with two undesirable > traits. I suggest it be reverted. I agree that it is too broken to keep in this state. Another symptom: 1. Open attachment 181299 [details] 2. Click once on the second field on Page 1, in row "TIME SPENT" (between "from" and "o'clock") 3. Backspace 4. Type some text Result: field is gone, text gets "eaten", and very buggy shifting in field shading. I checked that it indeed started at this commit, which is build [188a364571eaacfd90496bd956162bcf3ad85b6f] in linux-64-24.8 bibisect repo.
(I just realised Oliver is not in CC and not assigned anymore. Adding him to CC.)
(In reply to Justin L from comment #8) > It is worse than that. The entire field is removed This can be seen with non-protected documents like "Legacy Text Fields.docx" (bug 79435's attachment 100137 [details]) The revert is here: https://gerrit.libreoffice.org/c/core/+/167139
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/22dd422f7ccf7a1ce4dc7fe5b274263a55e464c7 Revert "tdf#150037 Writer: text fieldmark behaviour changed" It will be available in 24.8.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.