Bug 84543 - EDITING: Fields editing impossible ("read only") / hard (summary: comment 6)
Summary: EDITING: Fields editing impossible ("read only") / hard (summary: comment 6)
Status: CLOSED DUPLICATE of bug 64432
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) All
: high critical
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
Depends on:
Reported: 2014-10-01 08:20 UTC by Helge Kreutzmann
Modified: 2021-04-16 07:48 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

File 1: Original word file (504.00 KB, application/msword)
2014-10-01 08:20 UTC, Helge Kreutzmann
File 2, i.e. the rezipped one (41.67 KB, application/vnd.oasis.opendocument.text)
2014-10-01 08:22 UTC, Helge Kreutzmann
without... (67.68 KB, application/vnd.oasis.opendocument.text)
2014-10-01 19:45 UTC, Jacques Guilleron

Note You need to log in before you can comment on or make changes to this bug.
Description Helge Kreutzmann 2014-10-01 08:20:31 UTC
Created attachment 107166 [details]
File 1: Original word file

This might be several bugs, but they all pertain to one document. I labled the documents cited with [X] where "X" is a number (explained at the end) and the possible bugs with {}.

I have a document which I have to update several times a year. Originally, it was a word file[file 1] and I once (around 2008) saved it as odt and now I only copy the latest version and update the file. This worked with the Debian version of Openoffice.org / LibreOffice up to and including 1:3.5.4+dfsg2-0+deb7u2 (although with minor visual artifacts not relevant here).

Recently I upgraded to version 1:4.3.1-2. Now the fields no longer pop up in separate windows (I don't mind it, in fact, I think without windows is better), but unfortunately the entire file is write protected {bug 1}, i.e. also the fields themselves. This is reproducible with old copies up to the oldest once from 2008. Since the file(s) contain(s) sensitive information, I cannot provide it in the bug report. Instead I unzipped the odt, replaced the sensitive part in content.xml and zipped the resulting directory tree [file 2].

Strangely, this file I can now edit as expected, except that I get an I/O error, when LibreOffice quits and I confirmed that I want to save {bug 2}. Saving within the document still works (and keeps the content).(I rarely try this, so this bug might be older).

I tried the workaround from bug 70577 (which appears similar), however, then I cannot edit the fields anymore and after a few attempts to edit a field LibreOffice became unresponsive and I had to kill it from the console.

After deactivating the workaround from bug 70577 the previously read only files now can be edited as expected, however, the "I/O error when saving during close" as described above remains.

I also made a copy of the original word file [file 1], opened it and saved it as odt. This file worked as expected, except that I could not click on the beginning of fields, I had to use tab to get into them or click in the middle, otherwise an error popped up. However, this is no longer reproducible after trying the workaround from bug 70577 as described above :-((

I'm willing to provide information, run tests etc, please tell me what I should try to nail this down.

file 1: Original word file

Bugzilla doesn't let me attach a second file, I'll reply to this bug after submitting with the second file.
Comment 1 Helge Kreutzmann 2014-10-01 08:22:34 UTC
Created attachment 107167 [details]
File 2, i.e. the rezipped one

As stated, file 2 for the report.
Comment 2 Jean-Baptiste Faure 2014-10-01 12:43:33 UTC
Something like bug 76565 ?

Best regards. JBF
Comment 3 Jacques Guilleron 2014-10-01 19:45:41 UTC
Created attachment 107207 [details]

Hi Helge,

There's no longer write protection. But is there no other issues?


Comment 4 Helge Kreutzmann 2014-10-02 08:58:01 UTC
To Jean-Baptiste Faure:
Well, I did not try Ctrl-V and friends, I usually type in the values by hand. But I wasn't able to type anything in, I got an error telling me, that the file was read-only (I did not read anything about this in 76565). However, I might have started with backspaces (see below).

I created a new testuser and tried initial triggering file(s). I noticed the following behaviour: Inserting does work, but pressing backspace tells me (in German) in an pop up window (retranslated back): 
write-protected content cannot be changed.
This *also* occurs in my main installation. This also occurs in File 2 attached to this bug report (and the freshly attached one from Jacques).

In both installations, I'm no longer able to save the file after I pushed the backspace button, I get the message (again retranslated): 
Error saving the document test
General error
General Input/Output error

Saving during close, works however (and keeps the content).

To Jacques Guilleron:
I see no difference with the freshly attached file.

So to summarize:
a) Backspace does not seem to be supported in this file and version of LibreOffice in text fields.
b) Either during ordinary save or during save while quitting an I/O error occurs with this file (and its derivatives) while the other operations seems to work still (the file system was just checked today and there is 7,8 GB free space left).

Thanks for the quick reply!!
Comment 5 Jacques Guilleron 2014-10-03 16:25:07 UTC
Hi Helge,

I reproduce with LO Build ID: f9b3ad49d92181b0a1fe7e76f785a2c2cd0847d3
under Windows 7 Home Premium.
Protection against changes are extended to fields.
The last working version is LO (Build ID: e183d5b)
There, fields can be edited and entered correctly.
LO (Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7) don't allow to enter anything, but without warning. So this is also a regression.

I set Status to New, Hardware to All, and Importance to high critical.


Comment 6 Matthew Francis 2014-12-17 05:11:18 UTC
Two issues have been reported on this bug, so I'm forking it.

The issue that the behaviour of text fields in write-protected content is incorrect will be dealt with on this bug.

The issue that an I/O error occurs saving the attached file(s) will be dealt with on bug 87392
Comment 7 Matthew Francis 2014-12-17 06:23:47 UTC
Bibisect results from 43all:
Based on "File 2", there are multiple changes in the behaviour of editing the text fields between last41onmaster and latest.
(Whichever the correct behaviour for this file, the current 4.5 master behaviour that text can be inserted but not deleted is clearly incorrect)

1) Transition from with window, can add/delete -> with window, can't add/delete:
 a01d436b1ebb5cb163e7216a1e232000f4f0a87a is the first bad commit
commit a01d436b1ebb5cb163e7216a1e232000f4f0a87a
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Thu Oct 17 23:06:18 2013 +0000

    commit 9499df9f8c73ac6370c389683ce2028e6432441e
    Author:     Tor Lillqvist <tlillqvist@suse.com>
    AuthorDate: Mon Aug 12 09:28:57 2013 +0300
    Commit:     Tor Lillqvist <tlillqvist@suse.com>
    CommitDate: Mon Aug 12 09:28:57 2013 +0300
        Ifdef out code which had been accidentally un-commented-out
        The code snippet had been commented out since its introduction in
        2004. In 1452e5659796db395efa222d50cc8158275c5442 it was accidentally
        un-commented-out, but it causes compilation errors. So ifdef it out
        instead, with a comment. Note that I have no idea what the code does
        and whether it actually is useful to keep for future reference or not.
        Change-Id: Ie60ca065b2c65f86a7b382e246c1b650424daa1d

# bad: [e3a648fdaa2bb87293750400b70ba590733a804a] source-hash-33526481788137d959f27ae32910127d1436c1a8
# good: [c2069a369d738078124812312d51f21ea1ce2421] source-hash-f160e4935c474a5293b3d3c11b3d538efb4767a0
git bisect start 'e3a648fdaa2bb87293750400b70ba590733a804a' 'last41onmaster'
# good: [b886825d7eb2550ab40d7b4cd16de8096c57d6eb] source-hash-b46688a663b8709e0e0795f25ef8961db1f46cba
git bisect good b886825d7eb2550ab40d7b4cd16de8096c57d6eb
# bad: [f789e50909694bc398aaca477bc79ea38828034e] source-hash-e926621fb00f31471b0037d7955b6a3d7f908dc0
git bisect bad f789e50909694bc398aaca477bc79ea38828034e
# bad: [6dab1aaf04879f7ed6ca8baace99020b7f709443] source-hash-417d1c2b13cbd70300d2921b5667dfadc7e25895
git bisect bad 6dab1aaf04879f7ed6ca8baace99020b7f709443
# good: [a22bedaefd4f837e884f70bc50b0f916160b4c49] source-hash-a4c385f1aa98b5fb2d85136b653365fb6baa33f8
git bisect good a22bedaefd4f837e884f70bc50b0f916160b4c49
# good: [ec8f30b435a3d87aeba56822e715a9a53ef9b3d6] source-hash-ea4fc480c7317b16f4abbafacda3872bb7413357
git bisect good ec8f30b435a3d87aeba56822e715a9a53ef9b3d6
# bad: [f6a86d8812bc1db2fee07af4d54b7af6a553cc59] source-hash-e4ebe80be51fb33545091aa4f0bbc0ea2fe674f0
git bisect bad f6a86d8812bc1db2fee07af4d54b7af6a553cc59
# bad: [a01d436b1ebb5cb163e7216a1e232000f4f0a87a] source-hash-9499df9f8c73ac6370c389683ce2028e6432441e
git bisect bad a01d436b1ebb5cb163e7216a1e232000f4f0a87a
# first bad commit: [a01d436b1ebb5cb163e7216a1e232000f4f0a87a] source-hash-9499df9f8c73ac6370c389683ce2028e6432441e

2) Transition from with window, can't add/delete -> no window, can't add/delete:

There are only 'skip'ped commits left to test.
The first bad commit could be any of: 10aad62814a73c9f547fe1ae8b566b8905e62675 dbc806fd61243c2ae720c1c884758cc4d9f2073a
We cannot bisect more!

# bad: [33ac6698e6d90d84f99d784b9553ee87eec27d6a] source-hash-732c0f929fc0229b6da37d4ec4b6de8994fcea46
# good: [e3a648fdaa2bb87293750400b70ba590733a804a] source-hash-33526481788137d959f27ae32910127d1436c1a8
git bisect start '33ac6698e6d90d84f99d784b9553ee87eec27d6a' 'e3a648fdaa2bb87293750400b70ba590733a804a'
# good: [a1bd890a0802bd142798b7b601f370ca9c21426b] source-hash-04532617c7d264411563db24dc359326cc18eda7
git bisect good a1bd890a0802bd142798b7b601f370ca9c21426b
# good: [a1bd890a0802bd142798b7b601f370ca9c21426b] source-hash-04532617c7d264411563db24dc359326cc18eda7
git bisect good a1bd890a0802bd142798b7b601f370ca9c21426b
# good: [a1bd890a0802bd142798b7b601f370ca9c21426b] source-hash-04532617c7d264411563db24dc359326cc18eda7
git bisect good a1bd890a0802bd142798b7b601f370ca9c21426b
# bad: [3c257431da2650bf0d4ca7460af1b082c773816d] source-hash-1581b1fc3ac82a7bd62df968226e98604a4ca52d
git bisect bad 3c257431da2650bf0d4ca7460af1b082c773816d
# bad: [3c257431da2650bf0d4ca7460af1b082c773816d] source-hash-1581b1fc3ac82a7bd62df968226e98604a4ca52d
git bisect bad 3c257431da2650bf0d4ca7460af1b082c773816d
# good: [ffd0c9bc1f0028ea3b7cd1dfb6267992de21647c] source-hash-868103846b9b32bfecd77c08055fdca69d0265c2
git bisect good ffd0c9bc1f0028ea3b7cd1dfb6267992de21647c
# good: [ffd0c9bc1f0028ea3b7cd1dfb6267992de21647c] source-hash-868103846b9b32bfecd77c08055fdca69d0265c2
git bisect good ffd0c9bc1f0028ea3b7cd1dfb6267992de21647c
# bad: [dbc806fd61243c2ae720c1c884758cc4d9f2073a] source-hash-d7e4e5d35e66dbfcc30576d198e393661d84f616
git bisect bad dbc806fd61243c2ae720c1c884758cc4d9f2073a
# good: [c8a5658505930ebcd7ac5bc6057a6f7204f4e1d3] source-hash-547750e8c2d001f92e3e303ebfda9b395538e741
git bisect good c8a5658505930ebcd7ac5bc6057a6f7204f4e1d3
# good: [c8a5658505930ebcd7ac5bc6057a6f7204f4e1d3] source-hash-547750e8c2d001f92e3e303ebfda9b395538e741
git bisect good c8a5658505930ebcd7ac5bc6057a6f7204f4e1d3
# skip: [10aad62814a73c9f547fe1ae8b566b8905e62675] source-hash-e79c706ddda21f850fe3c5a867bacf3982e5b112
git bisect skip 10aad62814a73c9f547fe1ae8b566b8905e62675
# good: [4bc946d4de21c39a676394c1da0b714fcb9af011] source-hash-3dab6fcbedf21c1d2971527f6f99fa46d3d45514
git bisect good 4bc946d4de21c39a676394c1da0b714fcb9af011
# only skipped commits left to test
# possible first bad commit: [dbc806fd61243c2ae720c1c884758cc4d9f2073a] source-hash-d7e4e5d35e66dbfcc30576d198e393661d84f616
# possible first bad commit: [10aad62814a73c9f547fe1ae8b566b8905e62675] source-hash-e79c706ddda21f850fe3c5a867bacf3982e5b112

3) Transition from no window, can't add/delete -> no window, can't delete but can add:

There are only 'skip'ped commits left to test.
The first bad commit could be any of: 94d9d32ab850f35929d7d44328e6d1a68a9540a2 558a70aa9c9ae73a339b9782680cec98526bb823
We cannot bisect more!

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [33ac6698e6d90d84f99d784b9553ee87eec27d6a] source-hash-732c0f929fc0229b6da37d4ec4b6de8994fcea46
git bisect start 'latest' '33ac6698e6d90d84f99d784b9553ee87eec27d6a'
# bad: [0b79394752f7ecbab6ab4ecedbfab8551c6e9fbd] source-hash-381613916d42a1e18e2824b5d41028dcfe19659a
git bisect bad 0b79394752f7ecbab6ab4ecedbfab8551c6e9fbd
# good: [1da81d12775c421b7a04cd3a579fa555442c35f6] source-hash-ac01fd51822dc006abec578d61d66f7a169c19cb
git bisect good 1da81d12775c421b7a04cd3a579fa555442c35f6
# good: [6ded358e9af767e068952fb6aeafcf3e48421b32] source-hash-fec7d941d06b651013a8c08fa5128beacbad637d
git bisect good 6ded358e9af767e068952fb6aeafcf3e48421b32
# skip: [7c68a9acee7509bdb8fea95758604251f5ed9989] source-hash-c2a5369e6a64fd58bf87679c02002e0cc219c74d
git bisect skip 7c68a9acee7509bdb8fea95758604251f5ed9989
# bad: [0e47d65bd5b2b2e544679d254078754fa456ce3d] source-hash-09e5de8278dd8f13adcf614db35c8a8a04ba8e47
git bisect bad 0e47d65bd5b2b2e544679d254078754fa456ce3d
# skip: [5bdae03cc608c2897432a30a1bccc5c4738c1a27] source-hash-54ce662d3043fc0b892d8f000a6f5877e32b7325
git bisect skip 5bdae03cc608c2897432a30a1bccc5c4738c1a27
# bad: [b953294b1644c753897c13544a2af078a05fa4fd] source-hash-6e38e82b7ce2aeb3d7628ad518437c9af6eec0a8
git bisect bad b953294b1644c753897c13544a2af078a05fa4fd
# bad: [558a70aa9c9ae73a339b9782680cec98526bb823] source-hash-fedebb269e815a3475cefc21556031e09bb3f35e
git bisect bad 558a70aa9c9ae73a339b9782680cec98526bb823
# skip: [94d9d32ab850f35929d7d44328e6d1a68a9540a2] source-hash-278409c3f175b562453c8a7a0e139eadfe41ba11
git bisect skip 94d9d32ab850f35929d7d44328e6d1a68a9540a2
# only skipped commits left to test
# possible first bad commit: [558a70aa9c9ae73a339b9782680cec98526bb823] source-hash-fedebb269e815a3475cefc21556031e09bb3f35e
# possible first bad commit: [94d9d32ab850f35929d7d44328e6d1a68a9540a2] source-hash-278409c3f175b562453c8a7a0e139eadfe41ba11
Comment 8 Matthew Francis 2014-12-28 07:43:53 UTC
The following commit is where the behaviour appears to have changed most recently, which is probably the one that is significant in this instance.

Openoffice 4.1.1 (Aug 13 2014) allows both the adding and deleting of text within the input fields, so either this was mis-merged, or there was a follow-up fix which hasn't yet been applied

commit 961315f0838197e71e9bd49169afe673466e5eb8
Author: Oliver-Rainer Wittmann <orw@apache.org>
Date:   Thu Feb 20 11:01:04 2014 +0000

    Resolves: #i124243# allow in-place editing of Input Fields...
    in protected areas (e.g. protected sections)
    (cherry picked from commit 1708b9bee77ab0e8762bbb6886b778b93428a2b0)
    Change-Id: Iedcb31a824a9147bccb14314608749121c70d952
Comment 9 Matthew Francis 2014-12-28 08:38:16 UTC
Adding a Cc: to caolanm@redhat.com as the committer for the AOO merge mentioned above

Could you possibly take a look at this? Thanks
Comment 10 Matthew Francis 2015-01-16 13:14:05 UTC

*** This bug has been marked as a duplicate of bug 64432 ***
Comment 11 Robinson Tryon (qubit) 2015-12-15 11:03:27 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
Comment 12 Tammy M. Alexander 2020-01-17 06:19:26 UTC Comment hidden (spam)
Comment 13 shirwal 2021-04-16 06:07:15 UTC Comment hidden (spam)