Bug 80806

Summary: Not possible to edit input fields after creating it and write protecting section
Product: LibreOffice Reporter: birquito
Component: WriterAssignee: Not Assigned <libreoffice-bugs>
Status: RESOLVED DUPLICATE QA Contact:
Severity: normal    
Priority: medium CC: fdbugs, princeneosis, qubit, rb.henschel
Version: 4.2.5.2 release   
Hardware: x86-64 (AMD64)   
OS: All   
See Also: https://bugs.freedesktop.org/show_bug.cgi?id=75319
Whiteboard: possibleRegression
i915 platform: i915 features:
Attachments: ODT with an input field in a protected and unprotected section

Description birquito 2014-07-02 13:07:09 UTC
It's not possible to edit input fields in an write protected section anymore. The files are made from a selfmade templates where all sections are write protected, for only changeing the input fields not the rest of the document. 

To reproduce:
1. open a new writer file.
2. add an input field with text.
3. make the section write protected.
4. try to change the text in the input field.

You would be warned, that in the write protected area you are not allowed to write.
But I desprately have to do so. 

Same when you open an old file with input fields in protected sections.

I switched back to previously version 4.1.6.2 where all was/is working fine. Very uncomfortable because all extensions and configurations were lost.

By The Way: Double-clicking the field does not open an input window anymore - irritating. When not write protected and double-clicking a window opens, which I don't understand - nothning to change (only comment); all I can do at this point is switching between the fields. 
New normal behavior?

I hope my English is good enough to make myself clear.

greetings 

birquito
Comment 1 birquito 2014-07-05 20:33:37 UTC
I forgot something on the report:
It is very uncomfortable to change errors in an input field: a simple click highlights the whole field. A double click opens the window where nothing can be changed. Navigating within the field is only possible from the ege of the line, if clicking into the space after the text. Formerly it was possible to click the word or place I wanted to change in the dialog window.
 
Is this a bug or new behavior?
Is this another bug or a dependend?

birquito
Comment 2 birquito 2014-07-07 10:54:35 UTC
Some attempts to change or copy the text from the input field led to a crash of LO writer. Quickstart also goes down when closing Writer.
Comment 3 Regina Henschel 2014-07-07 20:28:17 UTC
The feature of inline editing of input fields has been introduced in Apache OpenOffice and copied to LibreOffice. In AOO it works as the reporter expects: Input fields are editable in write protected sections, and after a single click to activate the field a second single click sets the cursor at the click-position in the field.

Hi birquito@web.de, please try to find a reproducible way for the crash, and then open a new issue for it.
Comment 4 birquito 2014-07-11 08:04:45 UTC
Sorry, the crash seems to be an accident. Could not reproduct.
Comment 5 Owen Genat 2014-10-05 11:44:28 UTC
Created attachment 107357 [details]
ODT with an input field in a protected and unprotected section

This ODT was created in v3.3.4.1 and under GNU/Linux using:

v3.3.4.1 OOO330m19 Build: 401
v3.4.6.2 OOO340m1 Build: 602
v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
v3.6.7.2 Build ID: e183d5b
v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24
v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a

... both the field in the protected section and unprotected section are editable via single click with the hand mouse cursor. Under the same O/S using:

v4.2.6.3 Build ID: 3fd416d4c6db7d3204c17ce57a1d70f6e531ee21
v4.3.2.2 Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d
v4.4.0.0.alpha0+ Build ID: 65277f994ae25d930c15aebba0ed19f8de0abba1 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-09-29_19:47:20

... only the field in the unprotected section is editable in this manner. Clicking on the field in the protected section with the hand cursor simply results in the field being highlighted. The field in the protected section is however still editable via highlighting and CNTL+SHIFT+F9.
Comment 6 Owen Genat 2014-10-05 11:47:58 UTC
Operating system set to All. PossibleRegression added to Whiteboard.
Comment 7 Owen Genat 2014-10-05 11:49:36 UTC
*** Bug 82185 has been marked as a duplicate of this bug. ***
Comment 8 Owen Genat 2014-10-05 12:03:22 UTC
(In reply to Owen Genat from comment #5)
> Under the same O/S using:
> 
> v4.2.6.3 Build ID: 3fd416d4c6db7d3204c17ce57a1d70f6e531ee21
> v4.3.2.2 Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d
> v4.4.0.0.alpha0+ Build ID: 65277f994ae25d930c15aebba0ed19f8de0abba1
> TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time:
> 2014-09-29_19:47:20
> 
> ... only the field in the unprotected section is editable in this manner.

Sorry, this is inaccurate. Both fields are no longer editable in the single-click manner. Double-click on the field in the unprotected section results in the Edit Fields dialog being displayed (rather than the Input Field dialog).
Comment 9 Owen Genat 2014-10-05 12:50:09 UTC
After all that, it appears this is a partial duplicate of bug 75319. Added to See Also list.
Comment 10 Owen Genat 2014-10-05 12:58:00 UTC
(In reply to Owen Genat from comment #9)
> After all that, it appears this is a partial duplicate of bug 75319. 

Actually, bug 77205 would seem a more likely candidate. Apologies for all the posts.
Comment 11 castanheira 2014-11-20 01:38:13 UTC
Version 4.3.4.1 (Windows 8.1) is still buggy. When an input field is placed in a protected section, you can move cursor inside it with arrow keys and insert text in-place, but you CANNOT paste text with Ctrl-V (nothing happens), delete a character (a pop up says you cannot change a read only content) or backspace (same pop up).
Comment 12 birquito 2015-01-01 17:37:48 UTC
Still not working with LO 4.3.5.2. (Windows 8.1).

birquito
Comment 13 Matthew Francis 2015-01-16 13:12:17 UTC

*** This bug has been marked as a duplicate of bug 64432 ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.