This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 224184 - IDE forgets that File was saved
Summary: IDE forgets that File was saved
Status: RESOLVED WONTFIX
Alias: None
Product: editor
Classification: Unclassified
Component: Actions/Menu/Toolbar (show other bugs)
Version: 7.3
Hardware: PC Windows XP
: P4 normal (vote)
Assignee: Svata Dedic
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-23 19:19 UTC by bht
Modified: 2016-07-07 07:30 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Screen dump gif image (110.46 KB, image/gif)
2012-12-23 19:19 UTC, bht
Details
logs in zip file (44.46 KB, application/octet-stream)
2012-12-23 19:21 UTC, bht
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bht 2012-12-23 19:19:25 UTC
Created attachment 129657 [details]
Screen dump gif image

If I save a file in the editor and then close it fast enough then the editor still asks me if I want to save it.

In such case, the editor tab label has already normal font indicating the file was saved. If I decline (click Discard), and then re-open the file then it was indeed saved.

I don't yet know a way yet to give you a testcase for this because it happens only in my environment where the computer is slow and many projects are open.
Comment 1 bht 2012-12-23 19:21:54 UTC
Created attachment 129658 [details]
logs in zip file

Logs with setting -J-Dorg.openide.text.CloneableEditorSupport.level=FINE
Comment 2 Svata Dedic 2013-06-26 12:40:59 UTC
will try to reproduce/simulate
Comment 3 Svata Dedic 2013-06-26 19:22:22 UTC
Well, you have to be really, REALLY fast. I managed to reproduce the defect twice (saving and closing using keyboard shortcuts).

It seems the 'race' is between pending Save, which most probably already took a snapshot of the Document into memory and is writing the contents to the output stream, and a parallel close action, which still sees the document modified -- and it is indeed modified, as the memory buffer is still not completely flushed.

The close operation cannot be really synchronized with the save process IMHO - it checks the current state at one point of time while the save operation is proceeding. The error becomes much more visible with a slow (e.g. remote, NFS) filesystem, since the critical time starts when the editor content is flushed into memory buffer (that is done under atomic lock, and even AWT rendering - means other commands as well) are likely to be blocked, and ends when the buffer is written out and Savable cleared from the Lookup.

It is not safe to assume the editor is clear when the save operation *starts*, since when the write-out fails, the editor must be still open for the user to recover the contents; so observing Savable and NOT allowing to close the editor while save is under way is correct, IMHO.

A safe workaround can be implemented though. 

(A) The close operation may observe and watch the Savable state of the bad guys; if the Savable state changes during the dialog display, it means the question is useless (file was saved). The dialog could close leaving a message in the status bar explaining why the dialog was dismissed. Alternatively the dialog content could change indicating the editor was saved by another pending operation.

(B) An extension of the above idea is to create an extension of Savable, which could indicate the Save operation is proceeding. Then the dialog could contain more precise information initally (e.g. "The editor is being just saved, wait for the operation to complete, or close the editor even though the data was not yet fully saved")

I would suggest a simple implementation of (A) with just a status message.

Opinions (Mila - functional check, Petr - UI acceptance) ?
Comment 4 Svata Dedic 2013-06-26 19:28:33 UTC
An additional thought: given the severity (just annoyance, no data loss, no failure or not completed operation), and probability (occurs only on slow filesystems, or overloaded machines) I would classify the defect as P4.
Comment 5 bht 2013-06-26 21:13:46 UTC
I agree with P4 priority. I have raised this only to potentially assist with the solution of bug 206513 where the opposite happened - files weren't saved.
Comment 6 Petr Somol 2013-06-27 09:09:35 UTC
> 
> A safe workaround can be implemented though. 
> 
> (A) The close operation may observe and watch the Savable state of the bad
> guys; if the Savable state changes during the dialog display, it means the
> question is useless (file was saved). The dialog could close leaving a message
> in the status bar explaining why the dialog was dismissed. Alternatively the
> dialog content could change indicating the editor was saved by another pending
> operation.
> 
> (B) An extension of the above idea is to create an extension of Savable, which
> could indicate the Save operation is proceeding. Then the dialog could contain
> more precise information initally (e.g. "The editor is being just saved, wait
> for the operation to complete, or close the editor even though the data was not
> yet fully saved")
> 
> I would suggest a simple implementation of (A) with just a status message.
> 
> Opinions (Mila - functional check, Petr - UI acceptance) ?


Not very good news from UI point of view I am afraid - the two (A) options are one bad and one less bad. Changing the contents of the opened dialog is unacceptable - unless it had been indicated from the start that the dialog is in some way dynamic. Like if from the beginning a progressbar labeled something like "verifying save status" would be displayed, then it would come as no surprise to the user that progress has finished at some point and the changed dialog state is communicated. If, however, an ordinary dialog with static contents is displayed, and then suddenly it changes the contents, it seems weird and unstable and may even be overlooked - so to prevent overlooking one would have to emphasize the change content somehow, but emphasis here is not very convenient as it would suggest something quite important has happened what actually is not that much of a case.
Dismissing an opened dialog at some moment without user intervention is not a good practice either. If for nothing else, than for the following reason: user might have just been clicking dialog button or pressing a mnemonic; if the dialog disappears at exactly that moment, the user action can actually become interpreted by the editor underneath, leading not only to unexpected changes in text but also to unexpected change of saved status, etc.
From UI point of view it would be much better not to put the burden of any unexpected UI behavior to the user. What you describe as (B) above is much cleaner from UI perspective than (A) I am afraid.
Comment 7 Svata Dedic 2013-06-28 08:26:16 UTC
OK; the extended interface might be also (I think) useful if the save takes a long time not because slow IDE, but e.g. remote FS as in CND case - Vladidir did you experience some UI issues with slow saving ?
Comment 8 Vladimir Voskresensky 2013-07-02 10:36:31 UTC
(In reply to comment #7)
> OK; the extended interface might be also (I think) useful if the save takes a
> long time not because slow IDE, but e.g. remote FS as in CND case - Vladidir
> did you experience some UI issues with slow saving ?
Yes, we have problems with slow saving due to save on remote.
It occurs when save is synchronious (in Studio). 

Btw, I think NB has async sync be default.
If I remember correctly, side effect was: data races and incrorrect modified state of document.

In Studio we use synchronious save to prevent data races side effects.
Comment 9 Martin Balin 2016-07-07 07:30:26 UTC
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss