Bug 66071 - When Undo is used too often, no prompt to save document on close
Summary: When Undo is used too often, no prompt to save document on close
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.6 release
Hardware: Other All
: medium major
Assignee: Michael Stahl (allotropia)
URL:
Whiteboard: target:4.2.0 target:4.1.2 target:4.0.6
Keywords: regression
Depends on:
Blocks: mab4.0
  Show dependency treegraph
 
Reported: 2013-06-23 08:12 UTC by Thomas Hackert
Modified: 2013-08-14 17:55 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Backtrace using "soffice --backtrace" (4.20 KB, application/zip)
2013-06-23 17:49 UTC, Thomas Hackert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Hackert 2013-06-23 08:12:07 UTC
Hello @ll,
I hope, I have chosen the right component and have not missed an already reported bug ... ;) If so, feel free to change the component or closed this bug as dup ... ;)

Steps to reproduce:
1. Open Writer
2. Enter a word per line until you are on page 2
3. Open the Gallery via "Tools - Gallery
4. Drag the left topmost picture after your last word (this shouldn't have to do anything with this bug, but as I was triaging a but, when I stumbled upon this one, I am not sure about it ... :( )
5. Press <Ctrl>+<Z> (or "Edit - Undo") as often as you can
6. You should see a greyed out Undo button
7. Press either <Ctrl>+<W> or open a new document

Observed: Writer closes silently the new created "Untitle 1" window and either closes
Expected: Writer should asked to save the document or open a new document without closing "Untitled 1"

LO: Version: 4.1.0.1 Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155
OS: Debian Testing AMD64

Sorry for the inconvenience
Thomas.
Comment 1 retired 2013-06-23 15:29:13 UTC
Nice finding thackert.

I can confirm this on Ubuntu 13.04 + LO 4.0.2.2.

After undoing all I could undo and then hitting CTRL + W the document closes without giving the user the option to save it.

Also reproducible on OS X 10.8.4.

Setting to NEW. Changing platform to ALL.
Comment 2 Jorendc 2013-06-23 15:37:33 UTC
No crash reproducible using LibreOffice 4.0.4.2 with Linux Mint 15 x64 -> so regression.

I'll try to get a backtrace
Comment 3 Florian Reisinger 2013-06-23 16:26:30 UTC
Hi Thomas,

Sorry for the late answer and no triage work from my side...
My 2c:
Could it theoretically be this way:
If you undo <max number of undo steps> imes, LibreOffice thinks, that the document is empty and behaves like this:
-Not asking to save on closing -> no crash

I could reproduce this with 4.0.4.2 @ Ubuntu x64

@Joren: so no regression...
Ideas?
Comment 4 Jorendc 2013-06-23 16:38:50 UTC
I really fail to reproduce this :s ... Also not reproducible using Linux Mint 15 x64 with LibreOffice Version: 4.2.0.0.alpha0+
Build ID: 87c50e75633f31b54bfa1758cc0921ac53c6b418

... so no backtrace from my side :(
Comment 5 Thomas Hackert 2013-06-23 17:49:17 UTC
Created attachment 81279 [details]
Backtrace using "soffice --backtrace"

Hello Joren, *,
I have attached a backtrace, which I got with "soffice --backtrace" (which is unzipped 28KB, so I zipped it ... ;) ). I hope, it is of any use for you ... ;)
TIA
Thomas.
Comment 6 bfoman (inactive) 2013-06-25 08:10:45 UTC
(In reply to comment #0)
> 7. Press either <Ctrl>+<W> or open a new document
> Observed: Writer closes silently the new created "Untitle 1" window and
> either closes
> Expected: Writer should asked to save the document or open a new document
> without closing "Untitled 1"

Confirmed with:
LO 4.2.0.0.alfa0
Build ID: 2013-06-24 own debug build 
Windows 7 Professional SP1 64 bit

Ctrl+W - LO exits to StartCenter even when there is content in new file without prompt to save file. No crash.
Comment 7 Caolán McNamara 2013-06-27 15:04:08 UTC
So.... the backtrace in comment #5 has neon and ssl in it, so I think that backtrace is actually for bug #66009 (reported by the same user, so that makes sense) and not this actual bug.

In the original comment, and all the other ones, there is no crash as far as I can see, but a failure to prompt to save when closing the document. So I've retitled this bug as "When Undo is used too often, no prompt to save document on close."

*But* if this is a document where undo has undone every change to the document then there are no changes to save then that's the correct behaviour. i.e. the exact same behaviour we have with a blank new document, you can close that without getting prompted to save it too.

So the question now is: Is there a bug where we have a document which *does* have changes in it which causes no prompt to save when you attempt to close ?

bfoman: Your comment suggests there is ?, if so how to reproduce a situation where there are unsaved changes and no prompt to save on close ?
Comment 8 bfoman (inactive) 2013-06-27 15:42:39 UTC
(In reply to comment #7)
> So the question now is: Is there a bug where we have a document which *does*
> have changes in it which causes no prompt to save when you attempt to close ?
> bfoman: Your comment suggests there is ?, if so how to reproduce a situation
> where there are unsaved changes and no prompt to save on close ?

Just add a letter per line till you are over default 100 undos limit (or change it to lower value) and start undoing. Ctrl+w when you are done and you will go back to StartCenter. The document with rest of changes will be lost. No prompt to save.
Comment 9 Caolán McNamara 2013-06-27 16:03:53 UTC
indeed, confirmed.
Comment 10 Caolán McNamara 2013-06-27 16:18:00 UTC
like this all the way back to 3.5 AFAICS
Comment 11 Caolán McNamara 2013-06-27 16:37:17 UTC
caolanm->mstahl: What do you think. 
a) We add a flag to the undo manager that the undo limit was reached at some point so that an empty undo stack doesn't mean there was no modifications to the document. 

b) Or (cheaper) remove the m_rState.ResetModified in sw/source/core/undo/docundo.cxx currently hooked off SdrUndoManager::HasTopUndoActionMark on the basis that calc, draw, impress, math etc don't appear to ever unset their modified state when undo-ed back to the start and writer is the odd one out.
Comment 12 Michael Meeks 2013-07-01 16:03:34 UTC
Adjusting - clearly a rather old MAB then if it affects 3.5 :-)
Comment 13 tommy27 2013-07-01 16:15:19 UTC
changing version to last 3.5 release
Comment 14 Terrence Enger 2013-07-04 01:09:29 UTC
> caolanm->mstahl: What do you think. 
> a) We add a flag to the undo manager that the undo limit was reached at some
> point so that an empty undo stack doesn't mean there was no modifications to
> the document. 

Well, I find it useful to have the document-modified flag cleared when
I undo everything I have done.  Could this be accomplished by saving
the document-modified flag with each undo entry and restoring the flag
when the action is undone?

> b) ... calc, draw, impress, math etc don't appear to ever unset their
> modified state when undo-ed back to the start and writer is the odd one out.

As an occasional user of Calc, I would like it to reset the
document-modified flag when everything has been undone back to the
original state of the file.

Terry.
Comment 15 tommy27 2013-08-12 13:17:49 UTC
confirmed on Win7 64bit using LibO 4.0.4.
changing platform to ALL
moving this from mab3.6 list (3.6.x is EOL) to mab4.0 list.
Comment 16 tommy27 2013-08-12 13:23:03 UTC
I was also able to reproduce it in LibO 3.4.6 while it worked in LibO 3.3.4

changed version field and added regressione keyword.
Comment 17 Michael Stahl (allotropia) 2013-08-12 22:11:10 UTC
most likely regression from OOo 3.4 beta, CWS undoapi

fixed on master
Comment 18 Commit Notification 2013-08-12 22:18:14 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1ff7dfa533b473d721c372ae801a46ecd513b32f

fdo#66071: SfxUndoManager: allow Writer to set modified status properly



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 19 Commit Notification 2013-08-13 07:58:24 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2dbff02d9de9d2211a1c000663f3d6f2566d195a&h=libreoffice-4-1

fdo#66071: SfxUndoManager: allow Writer to set modified status properly


It will be available in LibreOffice 4.1.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 20 Commit Notification 2013-08-14 17:55:08 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=651f3bfa7bc843e778c851e6cafc32e401c3890d&h=libreoffice-4-0

fdo#66071: SfxUndoManager: allow Writer to set modified status properly


It will be available in LibreOffice 4.0.6.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.