Bug Hunting Session
Bug 75319 - Text in field not editable
Summary: Text in field not editable
Status: RESOLVED DUPLICATE of bug 79877
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.3.1 rc
Hardware: Other All
: medium enhancement
Assignee: Björn Michaelsen
URL:
Whiteboard:
Keywords: bibisected, regression
: 75995 76833 84243 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-02-21 11:52 UTC by Draga
Modified: 2015-12-15 11:03 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
template with input field (8.36 KB, application/vnd.oasis.opendocument.text-template)
2014-02-23 22:39 UTC, Cor Nouws
Details
display bugs whith templates (65.10 KB, image/jpeg)
2014-03-24 05:53 UTC, Draga
Details
Screenshot of pop-up window (205.87 KB, image/jpeg)
2014-10-06 07:51 UTC, Martin L ü c h e m
Details
Screenshot LibreOffice Version (152.93 KB, image/jpeg)
2014-10-06 07:51 UTC, Martin L ü c h e m
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Draga 2014-02-21 11:52:42 UTC
New text document.
Insert / Fields / other / Function / Input field
Save as: ODF Text Document Template (ott)

New document from this template.
We have dialog "Input Field".
Type text, press [OK]

Now text in field uneditable. Dialog box does not show.
Save document, open, click at InputField, dialog box does not show.

LibO 4.1.5 haven't this bug. Text in the InputField editable with dialog box.
Comment 1 Cor Nouws 2014-02-23 22:39:16 UTC
Hi Draga,

thanks for the issue.
It works fine for me in 4.2.1.1 on Ubuntu.
Will attach the file..

Can you pls chaeck that one?
thanks,
Cor
Comment 2 Cor Nouws 2014-02-23 22:39:42 UTC
Created attachment 94626 [details]
template with input field
Comment 3 Draga 2014-02-24 04:29:22 UTC
LibO 4.2.1.1 (4.2.0.4), WinXP

Open: 75319_tst_cornouws.ott
Created: Untitled 1
Auto opened dialog "Input Field": 
 Edit: testInputField
 in editbox: xxx

Change (or not): xxx
Press [OK]/[Cancel]/[Next], dialog box closes.
One click at testInputField - no response.
DblClick - dialog "Edit Fields" for editing testInputField.
Now I can not change testInputField contents.
Save "Untitled 1.odt", close, open.
Does not change the contents of testInputField.
Comment 4 sophie 2014-02-26 16:11:26 UTC
Confirmed using Version: 4.2.1.1
Build ID: d7dbbd7842e6a58b0f521599204e827654e1fb8b Ubuntu 13.10. Clicking on the field doesn't edit it and the cursor is not changed too. 
Tested under 4.1.5.3 under Debian 6 is working well. 
Set regression keyword, set to new - Sophie
Comment 5 Björn Michaelsen 2014-03-16 17:47:54 UTC
# bad: [f36b371d24b8b7212e611431b1c26449dc2a5375] source-hash-1581b1fc3ac82a7bd62df968226e98604a4ca52d
# good: [24c6e7658aaf3e673948c97db16265a2f6cd2432] source-hash-90830788b1f8fd61ea86135712868aeda395edd0
git bisect start 'latest' 'oldest'
# good: [ddb00a71f5ed8b8e4fa2157a519614c69af6477c] source-hash-5d0051efb99c6cbd0dc4dd655a71e7435159f6bc
git bisect good ddb00a71f5ed8b8e4fa2157a519614c69af6477c
# good: [c18767dea6ff322d3625806c98a7048d61403be2] source-hash-4ac9fa7a887d09edf7f1fc38f155a93cff30ac97
git bisect good c18767dea6ff322d3625806c98a7048d61403be2
# good: [024c6b9c9d5e995242d69d24958a64e907dc30fb] source-hash-9ab89a7599f79092027ae86b5b4cd0e3d67b8b4d
git bisect good 024c6b9c9d5e995242d69d24958a64e907dc30fb
# bad: [174dd5e8aac55aa53b2ef3116aac9f7c4f7def72] source-hash-5a3143c1a44d4c9d922aa33812d7c428664a8cf9
git bisect bad 174dd5e8aac55aa53b2ef3116aac9f7c4f7def72
# good: [f67315a2d234934add3a6bc5dd7b8df58304dcef] source-hash-3dab6fcbedf21c1d2971527f6f99fa46d3d45514
git bisect good f67315a2d234934add3a6bc5dd7b8df58304dcef
# bad: [3936d414a5394bc6f13a2903c1be5288828d0e3f] source-hash-d7e4e5d35e66dbfcc30576d198e393661d84f616
git bisect bad 3936d414a5394bc6f13a2903c1be5288828d0e3f
# skip: [3f4e0d91dcb02a64c961fa8b9ce02b58a0be2da3] source-hash-e79c706ddda21f850fe3c5a867bacf3982e5b112
git bisect skip 3f4e0d91dcb02a64c961fa8b9ce02b58a0be2da3
# only skipped commits left to test
# possible first bad commit: [3936d414a5394bc6f13a2903c1be5288828d0e3f] source-hash-d7e4e5d35e66dbfcc30576d198e393661d84f616
# possible first bad commit: [3f4e0d91dcb02a64c961fa8b9ce02b58a0be2da3] source-hash-e79c706ddda21f850fe3c5a867bacf3982e5b112

http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=3dab6fcbedf21c1d2971527f6f99fa46d3d45514..d7e4e5d35e66dbfcc30576d198e393661d84f616

Most likely cause is again:
commit c2b5521921b806ff7b04cdacebde3834d2aafd4b
Author: Oliver-Rainer Wittmann <orw@apache.org>
Date:   Mon Nov 18 11:29:24 2013 +0000

    Resolves: #i33737# enable in-place editing of Input Fields     
    (cherry picked from commit c2afeb1c3f11e8f420b59f3786eb8626c99ff595)
Comment 6 Björn Michaelsen 2014-03-23 14:51:31 UTC
Hmmm, I cant reproduce this on 4.1.3~rc1 or on master: Opening the attached .ott shows a dialog box at start. A double click bring up the field dialog and the field is modifiable inline. Can you recheck, so this can be closed as RESOLVED/WORKSFORME?
Comment 7 Draga 2014-03-24 05:32:24 UTC
LibO 4.2.3.1 (cleared profile)

Create document from 75319_tst_cornouws.ott
Opens dialog box "Input field" for edit "testInputfield".
Leave "xxx" (or type something) and press OK (dialog box is closed).
One click at field "testInputfield" - no dialog box "Input field". Now there is no opportunity to edit text.
In LibO 4.1.5 opens dialog box "Input field" for edit entered text.
DblClick at testInputfield opens dialog "Edit Fields" for edit field.
Comment 8 Draga 2014-03-24 05:53:04 UTC
Created attachment 96268 [details]
display bugs whith templates
Comment 9 Draga 2014-03-24 06:05:37 UTC
I checked LibO 4.2.3.1 with my templates. One of my template have: Input field, Input list.

1. In LibO 4.2.3.1 works correctly "Input list". I may choose item and rechoose (it's didn't work in 4.2.0).

2. Now I have bug with display "Input field". After all fields I have any chars (selected in attachment 96268 [details]). After typing text in input fields these artifacts vanish (only after each field). This bug only at disply, printing - without.
Where is no this display bug in LibO 4.2.0, 4.1.5
Comment 10 Draga 2014-03-24 06:31:33 UTC
Addon for last message, for item 2.
These symbols can't be removed from template. They don't exist. 
If after field exist any text, these symbols display over the text. If after field follow new paragraph and If resolve show "Nonprinting Charasters (Ctrl+F10)", these symbols displays after ¶.
Comment 11 Björn Michaelsen 2014-03-24 10:20:34 UTC
(In reply to comment #9)
> 1. In LibO 4.2.3.1 works correctly "Input list".

Closing as RESOLVED/WORKKSFORME then.

> After all fields I have any chars (selected in attachment 96268 [details]).
> After typing text in input fields these artifacts vanish (only after each field).

Please dont mix issues. Also that is issue fdo#75376, please continue there:

 https://bugs.freedesktop.org/show_bug.cgi?id=75376
Comment 12 Draga 2014-03-24 10:34:43 UTC
Bug 75319 is about "Input field" and isn't corrected.
"Input field" and "Input list" (in comment 9) are different fields.
REOPEN for correction.
Comment 13 Björn Michaelsen 2014-03-24 11:09:35 UTC
Works perfectly fine on Linux 4.2.3~rc1 as per comment 6. As possibly related fdo#75376 is Windows only, maybe this one is too. A second confirmation on any platform would be great (or someone confirming independently that the bug doesnt reproduce -- please state your platform then!).
Comment 14 Draga 2014-03-24 11:53:46 UTC
See Comment 3 : WinXP

Now checked and bug 75319 exists: Win XP pro SP3 (LibO 4.3.2.1, 4.2.0.4), Win 7 Home Premium x64 SP1 (LibO 4.2.0.4), Win 7 Pro x32 SP1 (LibO 4.3.2.1, 4.2.2.1, 4.2.0.4)
Comment 15 sophie 2014-03-24 12:51:14 UTC
So, I tested with Cor template, 4.1.5.3 Debian 6 = works fine, to reproduce: 
- Open the document, 
- in the dialog that pop up, change xxx to bla, 
- close with ok. 
- hover the field, the cursor is changed to a hand 
- click once the field, the same dialog box opens again and you can modify the content of the field

tested with 4.2.3.1 Ubuntu 13.10 = it doesn't work
- open the document
- in the dialog that pop up, change xxx to bla,
- close with ok
- hover the field, the cursor doesn't change 
- click once the field, nothing happen.
--> you can not change the content of the field any more.
Sopĥie
Comment 16 Björn Michaelsen 2014-03-24 14:01:49 UTC
Most strange, I have different behaviour on Ubuntu 14.04 (trusty) with libreoffice-4.2.3~rc1 from the prereleases PPA
(In reply to comment #15)
> tested with 4.2.3.1 Ubuntu 13.10 = it doesn't work
> - open the document
> - in the dialog that pop up, change xxx to bla,
> - close with ok

that works and changes the content of the field here

> - hover the field, the cursor doesn't change 

it does here

> - click once the field, nothing happen.

clicking once, marks the field content

> --> you can not change the content of the field any more.

clicking twice, opens the "Edit Fields" dialog and indeed the content is not editable _there_, but that is an expected outcome of the i#33737 fix.

However, moving the cursor into the field allows to edit the fieldcontent just fine.
Comment 17 sophie 2014-03-24 14:27:11 UTC
ok, now that I've read the relative issue, I can edit the field in place and exit it with arrows. I was not aware of the changes sorry, setting issue as Worksforme as this is now the new behavior - Sophie
Comment 18 Draga 2014-03-31 06:27:04 UTC
(In reply to comment #16)

> However, moving the cursor into the field allows to edit the field-content
> just fine.

1. Now I have no way to specify the desired position with the mouse to edit text in field. Dialog gives this opportunity (If the field has a lot of text, it comfortably).
2. Different behavior of objects (Input field and Input list) is bad for users: editing "Input field" is only in text and "Input list" is only in dialog.
Comment 19 Björn Michaelsen 2014-03-31 09:25:16 UTC
(In reply to comment #18)
> 1. Now I have no way to specify the desired position with the mouse to edit
> text in field. Dialog gives this opportunity (If the field has a lot of
> text, it comfortably).
> 2. Different behavior of objects (Input field and Input list) is bad for
> users: editing "Input field" is only in text and "Input list" is only in
> dialog.

Understood. I would suggest to file both of those issues as new well-scoped enhancement requests (severity: enhancement) referencing this one. For 2. its likely good to involve the UX team (https://wiki.documentfoundation.org/Design) on how an implementation that allow inline editing and consistency should look like.
Comment 20 Howdy 2014-04-15 16:34:02 UTC
This definitely does not "workforme."  

libreoffice-writer-4.2.3.2-3.fc20.x86_64


For some time now, this has been driving me crazy.  I had several templates for work with input fields, none of which work properly now.

1. If I open an ott, which is read only, it pops up the correct dialog ONCE, but wont allow me to change the contents(it used to).  After I close the dialog, I cannot open it again by clicking on it.

2. I cannot get the correct dialog, at all, on odt files, once the ott file is saved to this new format.  It is not a workable solution to just start typing inline, as it does not format correctly and if the last character of a word goes to the next line, ONLY that character goes to the next line.

3. Before, it would go through the document and prompt you with the dialog box to enter the text for each field.  This was ideal.  Obviously this does not work now either.
Comment 21 edonkey2001-libreoffice 2014-04-16 17:04:32 UTC
I confirm this Bug on Debian 7 with LO 4.2.3.3
Workaround: Ctrl+Shift+F9 works
Comment 22 KDM 2014-05-12 18:17:59 UTC
I seem to have the same/similar problem on Windows 7 using Version: 4.2.4.2. Loading a template, the initial field entry dialogs work as before. After that, I can navigate into, and edit the fields using the arrow keys (Which I like a lot!) but not using the mouse. Clicking once selects the field as a whole, clicking in the field again does nothing. A double-click opens the dialog, but won't allow editing the content.

Also I cannot find any way paste text into input fields--and I used-to do that all the time using the dialogs.
Comment 23 Charles 2014-06-02 20:50:36 UTC
Is my understanding correct that this is intentional and a new feature?

We have 60+ users, and I have just started rolling out 4.2.4 this past weekend, and I just got the first call today from someone who was unable to edit an Input field on a pre-existing document - then I got another call, then another.

They do this all the time - open an existing one, make a few simple changes, and save a new version.

Directly editing the fields is simply not going to work for us.

I discovered that you can directly edit the field, and the uses I have showed this too simply hate it, and have been begging me to install the old version.

Please tell me there is a way - and option/preference or something that I can change to get the old behavior back? Otherwise, I will have to roll back to the last version that allows editing the fields the old way (with the pop-up window) and we simply will not be upgrading Libreoffice again.

If there really is no going back, then this will be the final nail in the coffin of our adventure with Open/Libreoffice... and I truly hope this is not the case.
Comment 24 Charles 2014-06-10 11:43:15 UTC
Question...

Since apparently this is indeed the new way for it to work, how can I easily edit these input fields inline by copy/paste? It simply doesn't seem to work.

 We have a ton of users who routinely replace text in these fields with new text using copy/paste. We simply cannot upgrade until this is possible.

Question 2...

Since CTRL-SHIFT-F9 still re-initiates the pop-up prompt for field entry, why is there not a preference to go back to the old way?

I really dislike inline editing - these pop-ups is one of many things that I liked better than the Microsoft way.

Is an 'enhancement' request to allow a pref to go back to the old behavior likely to be implemented?
Comment 25 Atila 2014-06-17 14:25:28 UTC
Added enhancement issue 125108.
Comment 26 Charles 2014-06-20 12:23:20 UTC
I can't find issue 125108...

This hugely problematic bug is still present in 4.2.5.

This is getting ridiculous.
Comment 27 Owen Genat (retired) 2014-10-05 12:53:55 UTC
*** Bug 76833 has been marked as a duplicate of this bug. ***
Comment 28 Jean-Baptiste Faure 2014-10-06 04:56:25 UTC
*** Bug 75995 has been marked as a duplicate of this bug. ***
Comment 29 Martin L ü c h e m 2014-10-06 07:51:08 UTC
Created attachment 107394 [details]
Screenshot of pop-up window

Hi all,

coming from bug 75995, what seems to be a duplicate, I must state after years of following open source development: No matter if this is a way of working voluntarily (by the way: I donated!) I would expect a change of behavior to be described in LibreOffiec/OpenOffice Help. Up to now I did not find any description in there that Input Field behavior has been changed. So may questions are:

1. Did behavior change or not?

2. Is there a solution for getting "change option on input field" back again?

Regards, Martin
Comment 30 Martin L ü c h e m 2014-10-06 07:51:47 UTC
Created attachment 107395 [details]
Screenshot LibreOffice Version
Comment 31 sophie 2014-10-22 15:08:33 UTC
*** Bug 84243 has been marked as a duplicate of this bug. ***
Comment 32 Cor Nouws 2014-11-04 21:50:21 UTC
Comment 19 clearly describes " 
Understood. I would suggest to file both of those issues as new well-scoped enhancement requests (severity: enhancement) referencing this one. For 2. its likely good to involve the UX team (https://wiki.documentfoundation.org/Design) on how an implementation that allow inline editing and consistency should look like. "

comment 25 gives " enhancement issue 125108. " that cannot be found ...

So pls give a link to the proper enhancement request. And then set to closed. Thanks,
Comment 33 Charles 2014-11-05 11:07:51 UTC
(In reply to Cor Nouws from comment #32)
> Comment 19 clearly describes " 
> Understood. I would suggest to file both of those issues as new well-scoped
> enhancement requests (severity: enhancement)

Thanks Cor,

I created an enhancement request back in June to simply provide an option to revert to the old behavior  (pop-up dialog rather than in-line editing of Input fields):

https://bugs.freedesktop.org/show_bug.cgi?id=79877

This is very, very important to our user base (60+, all Windows). I'm still getting major push back from almost all of them. In fact, only 2 - who apparently like the in-line (Word) way better - have expressed the desire to get the new version (4.3.3) where pasting is finally fixed. No one else wants the new version, and are stuck on 4.1.6.

Since the code for the old behavior is still there, it should be relatively easy to do this as an option, don't you think?

Even an option to just dbl-click the field to get the pop-up...
Comment 34 Cor Nouws 2014-11-05 11:43:06 UTC
Hi Charles,

(In reply to Charles from comment #33)

> I created an enhancement request back in June to simply provide an option to
> revert to the old behavior  (pop-up dialog rather than in-line editing of
> Input fields):
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=79877

Thanks. That is for #2 from comment 18 then

> Since the code for the old behavior is still there, it should be relatively
> easy to do this as an option, don't you think?

Hé, I'm afraid not. But my thoughts on this are worth nothing, sorry.

I also checked #1 in comment 18.
That is fixed in the mean time: you can put the cursor at any position in the field and type etc. (there is/was some issue with pasting, shouts my memory..)

So for convenience, I'll close this one a duplicate.

Cheers,
Cor

*** This bug has been marked as a duplicate of bug 79877 ***
Comment 35 Charles 2014-11-05 13:07:55 UTC
(In reply to Cor Nouws from comment #32)
> comment 25 gives " enhancement issue 125108. " that cannot be found ...
> 
> So pls give a link to the proper enhancement request. And then set to
> closed. Thanks,

Ah... found it...

Atila created that issue for Apache Openoffice:

https://issues.apache.org/ooo/show_bug.cgi?id=125108

I just commented there begging for a simply dbl-click feature to pop-up the old dialog for an individual field...

Hopefully Olivier (the original guy who did the in-line editing change) will have mercy on us and make it happen...
Comment 36 Robinson Tryon (qubit) 2015-12-15 11:03:37 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]