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.
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
Created attachment 94626 [details] template with input field
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.
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
# 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)
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?
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.
Created attachment 96268 [details] display bugs whith templates
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
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 ¶.
(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
Bug 75319 is about "Input field" and isn't corrected. "Input field" and "Input list" (in comment 9) are different fields. REOPEN for correction.
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!).
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)
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
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.
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
(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.
(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.
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.
I confirm this Bug on Debian 7 with LO 4.2.3.3 Workaround: Ctrl+Shift+F9 works
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.
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.
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?
Added enhancement issue 125108.
I can't find issue 125108... This hugely problematic bug is still present in 4.2.5. This is getting ridiculous.
*** Bug 76833 has been marked as a duplicate of this bug. ***
*** Bug 75995 has been marked as a duplicate of this bug. ***
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
Created attachment 107395 [details] Screenshot LibreOffice Version
*** Bug 84243 has been marked as a duplicate of this bug. ***
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,
(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...
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 ***
(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...
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]