Window to edit the input field is not displayed. Steps to reproduce: 1) Launch LibreOffice Writer 2) Select Menu "Insert-> Cross-reference…" 3) In the window "Fields", select "Functions" tab 4) Select "Type" "Input Field" 5) Type "test" in "Reference", and Press "Insert" button 6) In the window "Input Field", type the value 5, and Press "OK" button 7) In the window "Fields", press "Close" button 8) Double click in the "field" 5 Current behavior: When you double click in the input field, a window "Edit fields" is displayed. Expected behavior: Show a window "Input Field", for editing the value. Workaround: Press ctrl+shft+F9 Rwindows XP SP3 LibreOffice 4.2 branch, 4.3.0.0.beta1 and 4.4.0.0.alpha0+ (TinderBox: Win-x86@42, Branch:master, Time: 2014-05-22_01:05:33) Note: The branch 4.1 and earlier have correct behavior.
I can reproduce this issue with 4.3.0.0.beta1 Build ID: 2e39c7e59c8fc8b16a54c3d981dceef27fb0c07f4.3.0 which opens "Edit Fields". 4.1.6.2 opens "Input field" as described by João Mac-Cormick.
The old input fields were read-only so you had to double-click to get a dialog to change their value. The new ones are read-write so you just click on them (or cursor into them) and type to change their value. So now double clicking an input field is the same as e.g. double clicking a date/time field, the field dialog appears. So, just click on it once and type the desired replacement text and it should "just work"
Thank you. I knew I could change it by clicking. However there was a change in behavior, so I reported it as a possible bug.
I reopen this as a non functional UI BUG After deploying 4.3.0.4 we recieve a big number of complains after testing. The fact that double-click was changed create a lot of confusion without any benefit for end user. Here a list of the following trouble and inconsistencies found in last 4.3.0.4 (windows or linux have same behaviour) In the attached model if you copy and paste a long text in address field. And after that you want to change or two words, you can't double click on the word to select it. To be able to do a mouse selection you have to click on the field, then get out, then re click in the field, then you should be able to select a word or two. Now the funny things (not from a end user point of view) if you use delete you can delete the selected word. But if you use backtab a warning dialog box is opened saying read only field can't be edited ... Then there's a complete confusion in user mind. Now next point : using ctrl+shift+F9 is not a panacea, due to the fact that it restart editing field from 0 .. not the field you're on... Take a few seconds and imagine a form that has 32 fields and at the end of your work, you want to edit the number 28 ??? You have to clic 28 time on next ...
Created attachment 104878 [details] Sample of form use this form to follow the bug description
Summary edited for clarity. Note that if the essence of this report relates to editing input fields in protected sections, then bug 80806 is also related.
Closing this again - just because users haven't gotten used to a change does not mean it's a bug. A suggestion: If you are truly convinced of this, bring it up to the UX mailing list and get them to look at it. Reopening a bug that has a clear explanation of the change is not going to move anything forward. Ping the UX mailing list - see their thoughts, if they are convinced it needs change, report a separate bug to change the behavior back. Again, please don't do this unless you can get wide acceptance from the UX team.