Download it now!
Bug 32177 - Writer does not perceive addition of custom document properties as a change for saving
Summary: Writer does not perceive addition of custom document properties as a change f...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.0 RC1
Hardware: x86 (IA32) Windows (All)
: medium major
Assignee: Noel Power
URL:
Whiteboard:
Keywords:
: 35063 38640 40970 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-12-07 04:09 UTC by Christophe Strobbe
Modified: 2011-09-21 08:35 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christophe Strobbe 2010-12-07 04:09:09 UTC
When you add or fill in custom properties in an ODT file, this change is not recognised, so closing the document does not lead to a Save prompt, and both the Save button and the Save menu item (in the File menu) remain greyed out.

Steps to reproduce the bug:
1. Create a new text document in Writer, add some random text and save it.
2. Go to File > Properties > Custom Properties, and fill in a few properties.
3. Confirm the change by pressing the OK button in the Properties dialog.
4. Notice that the Save button on the toolbar and and Save item in the File menu are greyed out. Close the document: observe that Writer does not present a dialog that prompts you to save the changes.

Note: I could not reproduce this issue in LibreOffice Calc (nor in OpenOffice.org Writer 3.2.0).

Current workaround: use "Save as" after adding custom properties.
Comment 1 Federico Del Bene 2011-03-08 02:27:52 UTC
Confirmed with

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

and

LibreOffice 3.3.1 
OOO330m19 (Build:8)
tag libreoffice-3.3.1.2

I'm using Windows 7 Sp1 x64. Both Windows and LibO are Italian version.
Comment 2 Zack 2011-03-16 21:30:32 UTC
Also confirmed with 

LibreOffice 3.3.1 
OOO330m19 (Build:8)
tag libreoffice-3.3.1.2

on Linux (Kubuntu 10.04).
Comment 3 Thomas M. 2011-03-24 05:50:45 UTC
I confirm this behavior on :

  LibreOffice 3.3.2 
  OOO330m19 (Build:202)
  tag libreoffice-3.3.2.2, Debian package 1:3.3.2-1

The issue occurs both when new fields are added in the customer properties, but also when existing custom or standard fields are modified (e.g Document Title).

This is a very painful issue, because the user data can be silently lost. Let's take the following example:
- document is edited, then saved
- the user modifies or add document properties
- the user presses CTRL-S, and does not see that nothing happened
- the user closes the document, openoffice 
- the changes in the properties were lost
It happened to me on three files yesterday ; I noticed the bug because I actually had to re-open the property editing dialog to do another modification.

The effects can be very bad: take the example where the modification in the document properties consisted in removing a specific information in, e.g. the document title; if this change is lost, then the user gets a file that, even after saving as a PDF, will leak the information that the user wanted to remove.

Given the data loss issue described above, I'm marking this bug as 'critical'.
(I don't known the policy on whom is legitimate to position bug severity, but I think the use case above is clearly a user data loss)
Comment 4 Thomas M. 2011-03-24 05:51:22 UTC
*** Bug 35063 has been marked as a duplicate of this bug. ***
Comment 5 rl 2011-04-12 23:46:54 UTC
With LibreOffice 3.3.2 I can add file properties, but then not change them anymore later.

Modified file properties don't get saved and LibreOffice also doesn't update associated fields in the current file when properties get changed. (For the later see "Bug 30857 - The File-Properties set could not reflect to corresponding document fields.")

See this problem on Windows 7 (64 bit) and on Mac OS X 10.6.7.

No such problem with OpenOffice.org 3.3.0.
Comment 6 Rainer Bielefeld Retired 2011-04-26 03:16:46 UTC
[Reproducible] with "LibreOffice 3.3.2  – WIN7  Home Premium  (64bit) German UI [OOO330m19 (Build:202 / tag 3.3.2.2)]". No problem with CALC, DRAW!
3.4Beta not tested yet.

@Cédric:
Your area?
Comment 7 gibi 2011-05-17 12:56:23 UTC
[Reproducible] with LibreOffice 3.4.0beta5  – Windows
Works with Calc: floppy icon (Save) turns blue as soon as the properties window is closed.
Comment 8 AdamB. 2011-06-06 10:14:19 UTC
I have the same exactly the same problem when i tray save large document (about 130 pages), when I open document save is gray and always stand .lock file - LO 3.4 .
In LO 3.3 that problem didn't exist -cy
Comment 9 manj_k 2011-06-25 10:54:27 UTC
*** Bug 38640 has been marked as a duplicate of this bug. ***
Comment 10 Caolán McNamara 2011-08-09 09:17:41 UTC
SfxObjectShell::SetModified is called when "ok" is called in calc, but not in writer.
Comment 11 Caolán McNamara 2011-08-09 13:59:01 UTC
triggered by 9a3f243c and 0b21b8b1

If SfxBaseModel::getDocumentProperties is called with no prior XDocumentProperties one is created and a listener is added to it which sets the doc as modified if the properties changed.

But if SfxBaseModel::setDocumentProperties is called, then the new XDocumentProperties has no listener set on it, so changes to the properties don't set the document as modified.
Comment 12 Caolán McNamara 2011-08-09 14:05:59 UTC
http://cgit.freedesktop.org/libreoffice/core/commit/?id=10c0e027b8940e6cead7282fb69796cb28d2aeb9

add a listener to the XDocumentProperties that get set. Fixes this.

caolanm->noelp: be good to have a double-check of this for me. Maybe for 3-4 if necessary.

(Might be the case that we should store what we set as a listener in order to remove it as a listener to avoid leaks/circular references. Never sure about that, current code doesn't, so no worse there.)
Comment 13 Noel Power 2011-08-10 02:09:36 UTC
(In reply to comment #12)
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=10c0e027b8940e6cead7282fb69796cb28d2aeb9
> 
> add a listener to the XDocumentProperties that get set. Fixes this.
> 
> caolanm->noelp: be good to have a double-check of this for me. Maybe for 3-4 if
> necessary.
> 
> (Might be the case that we should store what we set as a listener in order to
> remove it as a listener to avoid leaks/circular references. Never sure about
> that, current code doesn't, so no worse there.)

looks ok to me ( like you say no worse than before ), I know no more about removal of the listener either :-/  have seen this before in many many places, presumably leaving it to the broadcaster's local list of listeners alone ensures there would be no leak ( or strange circular ref scenario like you mention ). 
I guess it is worth pushing this to 3.4 .
Have to say though that I don't know why I set the compatible "com.sun.star.writer.DocumentProperties" for 'normal' writer documents ( although the extra properties are hidden from the ui, only available from the uno api etc. ) Hmmm I can't remember whether it was intentional or not
Comment 14 manj_k 2011-09-21 08:35:24 UTC
*** Bug 40970 has been marked as a duplicate of this bug. ***