Problem description: Steps to reproduce: (1) Open new text document. Beginning of editing session 1, measure the time. (2) Set Option „Load/Save > General > Save > Edit document properties before saving” (3) Insert some words. (4) Save document: File > Save, type in file name, choose file type and choose directory, then ”Save“. The dialog “Properties of Untitled1” is displayed. Expected: “Properties of [file name] is displayed. (5) Click tab “General” Displayed file name: “Untitled”. Expected: file name typed in at step (4). Type: Text document. Expected: file type chosen in step (4). Location: A location is not displayed. Expected: path name chosen in step (4) Total editing time: 00:00:00, this is OK, hence the editing time is only updated, when the file is saved. (6) Click “OK”, document is saved. (End of session 1; beginning of session 2, hence the file is not closed) (7) Display properties: File > Properties.. File name, Type, Location are OK now. Total Editing time: still 00:00:00, Expected: Time period between “Created” and “Modified” = time period of session 1. The document has been saved, so the editing time should be updated. (8) Cancel properties dialog. (9) Insert some more words. (10) Close document with saving (End of session 2) and open it again. (11) Display properties: File > Properties.. File name, Type, Location are OK. Total Editing time is equal to the period of session 2. Expected: Total time period of both sessions. Comment to step (5): You can argue, that the displayed information of file name, file type and location are correct, hence the document has not been saved yet. But from my point of view it's quite irritating, when I just have determined name, type and location and one second later these data are not displayed. Possibly a message can be displayed in the property dialog: “Document has not been saved. It will be saved with OK.” I checked the mentioned behaviour only with Writer. But I assume, that the behaviour is identical with the other LibreOffice components. See also bug 48605. Browser: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20100101 Firefox/14.0.1
Created attachment 78295 [details] Screenshots with comments [Reproducible] with "LibreOffice 3.6.6.2 release " German UI/ German Locale [Build-ID: f969faf] {pull date 2013-04-03} on German WIN7 Home Premium (64bit), see attached screenshots
I did the second experiment (see screenshots) with LibO 3.3.3 (WIN7), Total editing time was shoen correctly. So this is a regression. I will check later when this started
Already [Reproducible] with Server Installation of "LibreOffice 3.5.1.2 German UI / English Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit) Still worked fine with Server Installation of "LibreOffice 3.4.5 German UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit)
So it seems this problem came with LibO 3.5?
currently only confirmed for WIN
*** Bug 63775 has been marked as a duplicate of this bug. ***
OS back to "ALL" due to DUP
Version is oldest version that we see the problem, not newest, we use comments for this. Reverted last change
This Bug also exits in version 3.6.X, 4.0.X and 4.1.0 Beta 1 and Beta 2 (Testsytems Windows XP, Vista and Debian 6.0, alll 32-bit)
Is it possible to Add this "longterm-bug" to "Bug 60270 - (mab4.1) LibreOffice 4.1 most annoying bugs"?? Thanks
I did by myself, hope its correct
Removing from 4.1 MAB for a couple reasons: 1. It doesn't really meet requirements for MAB - it's not that annoying, it's truly a minor bug, doesn't affect professional quality, etc.. etc... 2. Someone from QA or a developer needs to be the one who adds it 3. It wouldn't be a 4.1 MAB even if it was a MAB, it would be a 3.6 I will compare this to the other MAB and see if it's even close to as annoying as the other ones - if it is I'll add it myself, else please don't mess with the top section unless you're familiar with the workflow. Thanks for the additional info regarding versions
This is really quite a few bugs in one - what exactly is the MAB from it? The summary of the bug is somewhat misleading as it says the issue is the time adding up but the issues mentioned are quite a few (the things listed in step #5). Again none of these to me seem like a MAB as none of them even slow down work flow that much - lastly the time thing - I didn't even know about this and not sure what it's really used for that would qualify for a MAB. I suppose if someone was charging by the hour for something and needed an incredibly accurate time tracker...perhaps, else, really not a MAB compared to the ones we currently have on the list. Also with regards to the time point for #11 - this IS how it's supposed to work - this is clearly a result of point #5 where it says total time is 00:00:00 the first time you save and set the properties. Time isn't being kept until you save the document the first time - the total time is updated every time you save AFTER the 1st one. If we want it to be from the beginning of the document, it's actually an enhancement request as this isn't how things are designed. I'm wondering if time isn't kept until properties are set to avoid having to keep time for every single document - honestly that's a question for a developer. So my points: 1. Displayed file name: “Untitled”. Expected: file name typed in at step (4). Verified on pre-bibisect (likely came from OOo) 2. Location: A location is not displayed. Expected: path name chosen in step (4) Verified on pre-bibisect (likely came from OOo) 3. The time thing Verified on pre-bibisect (likely came from OOo) Updating version to 3.5 beta0 since I can confirm at least this far back Removing regression as I can't see where it worked - if someone can say where it worked let us know The time thing - IMO it's an ok enhancement request - but even as such it's very very minor. If you save the document immediately, from that point forward it tracks time, every time you save it'll update the counter Thoughts?
This bug exists still in Version LO 4.1
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01
In step 7 I had the correct time, not zero. Closing as WFM. Win 7 Pro 64-bit Version: 5.0.0.0.alpha0+ (x64) Build ID: 211c12b9c64facd1c12f637a5229bd6a6feb032a TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-18_01:51:17 Locale: fi_FI
Checked the "Total editing time" with severals release versions. It seemed this problem has been fixed in version 4.3.0. In version 4.2.4 it still exists. Furthermore I created a new bug report for problems mentioned in step (5) (bug 91204). Hence I closed this bug.