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
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.
When the box is clicked and content is typed/copied in, the existing space is removed and replaced by the entered value.
User Profile Reset: No
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: 188.8.131.52 / 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
Created attachment 181299 [details]
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: 184.108.40.206.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
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.
Version: 220.127.116.11.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
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":
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:
Affected users are encouraged to test the fix and report feedback.
Version: 18.104.22.168.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
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.