Closed vankasteelj closed 7 years ago
Tagging @ryanstewart @nethip @swmitra
Hey all, we're definitely hoping to track this down and if/when we find a fix, we'll push out an update ASAP. If others can post their extensions, that might help. Has anyone seen the issue when they've reloaded Brackets without extensions?
For me it happens without extensions as well as with.
Interesting permutation just happened for me: 1) hit ctrl + v to paste something, 2) ctrl + z to undo it, 3) ctrl + z again but it won't undo anything prior. It's like it breaks there. Not at save, but at paste. But sometimes it just stops working altogether. (Latest version, Win 8.)
I'm having this issue too. Undo history wiped after save. I do have a process running in the background that will compile all files in the directory after a save. So, I'm not sure, but it could have to do with another process touching the file.
I'm developing currently on Win7. Working with js, json, and html files, and it happens with all file types. I'll try on my Mac later today.
Same here. Impossible to do any work when you can't revert a change.
HTML, PHP, css, scss files, doesn't matter. With or without extensions.
Two different machines, one on Win7, the other on Win10. Reverting back to 1.4 until this gets sorted.
I'm unable to reproduce yet I haven't done any update. However, I stopped working on such a large repository (750+ files) and I'm now lighter (max 100 files). Maybe that's a lead?
@Madebym could you update back to 1.5. and see if you can repro the issue and check the dev console for possible errors?
New user here, I've been seeing the same thing on Win 10, Brackets 1.5, but for awhile it was easy to reproduce. I have a .JS file loaded in a small project. I have no extensions, and after doing "reload without extensions" just to be sure:
Type something and save. Ctrl+z. Would undo. Type something and save again. Ctrl+z. Would not undo.
It was breaking for me on the second save, every time. Just to try it, I created a new file and tried the same steps, except this time it worked -- and now I can (currently) save multiple times on any file without issue. Sadly, I didn't get to check the dev console. I too might have to revert if this keeps popping up, it's made for a few nasty surprises. Good luck, guys.
update on my 5-days-ago post: I jinxed it. It does bug again on that smaller project since I added lines :(
I continue to think it's linked to total nb of lines or something like that.
In #11967 @designcise mentioned that this seems to happen after Find in files
, which sounds like a potential culprit to me (as it was one of the biggest changes on 1.4-1.5. timeframe).
Find in files
are localised to node changes. That may not be the reason here. We also did a code mirror update, that could be the likely cause. I have not been able to repro this issue till now, so all these are speculations.
@abose I was thinking something along the lines of the node process touching the files during (or after) the save for whatever reasons (occasionally), prompting the file(s) to (instantly) reload -> causing CodeMirror/Brackets lose the history.
You have better insight on the node implementation than I do so I might be way off though.
The reason i said that is, when a file is edited in brackets, we do not suddenly initiate a cache update. we just remove the changed file contents from the cache. The changed file is read only the next time a user performs a search. So the indexer is inactive during most of the time. @swmitra was able to repro this once.
Hi, i'm using Brackets for Ubuntu 14.04 from 5 days ago and i have the same issue, i can't undo when save a file, but I'm unable to reproduce... Now i'm working with javascript files. it's really annoying... I have to try if i use brackets with no extension and look if the problem appear again... I have this extension:
Captured some debugging data today after getting hit by the issue:
https://gist.github.com/petetnt/f0693b2951c884c4dd20
(Note that the state after saving is the current cursor position)
tagging @swmitra @abhijitapte
Been using Brackets Release 1.5 build 1.5.0-16538 (release cf9cf4698) on Windows 10 64 bit since 4 December with PHP SmartHints & QuickDocs PHP extension and I can confirm that this problem happens so many times on my daily use even before i installed extensions. Undo is not working after saving files. The problem disappear after Reload without extension and Reload with extension.
I am using brackets Release 1.5 experimental build 1.5.0-16538 (release cf9cf4698) on ubuntu mate 15.04 64 bit. I confirm that I am facing the same issue.
Over two months in, and still no fix. And the release that has this bug is still on the website. Unbelievable.
Let me repeat myself: this bug can and will destroy work. A release with a bug like this should not exist. I can't believe you (devs) are so lax when it comes to something high-prio as this.
Sorry for that rant, but I don't want this to become the next breaking bug that has existed unresolved for over a year, like the Scrollwheel Bug.
I recently started having this problem and tested each extension individually. For me the problem seemed to only exist with this extension installed: https://github.com/zaggino/brackets-file-tree-exclude
I don't use a lot of extensions at one time though. Currently about 4 or 5 at the most. But this extension (brackets-file-tree-exclude) is the only one that makes this problem visible for me. Not saying it is the cause because I don't know.
Hello all,
in an effort to get this fixed before 2016 I created the following extension:
https://github.com/petetnt/corrupt-brackets-history
It's a tool that can be used to corrupt Brackets undo history by writing and saving to a file continuously until the history fails. The script also saves an Profile
with console.profile
every time it has been run, which can be used to find the root cause for this issue.
Sadly I am AFK for the next 3 days, so I cannot work on this issue until 29th. Hopefully someone else has the time between their Christmas :christmas_tree: holidays and whatnot to try and find the cause. It's understandable that users like @thany are frustrated with the issue, but like this issue proves it's also very hard to debug but we can hope that my extension would help the situation a bit.
I also have this issue and am able to reliably reproduce and not reproduce the issue.
I am using Brackets: Release 1.5 build 1.5.0-16538 (release cf9cf4698) On: Mac OS X 10.11.2 (15C50)
I regularly have projects that range in file numbers from 500 - > 20,000. The larger projects are usually using bower, grunt and composer so the extra files come from all the packages installed. This issue persists on all projects no matter the size.
For me this issue is pretty much constant, on every single file no matter how many lines or what type of file. Once I save I can no longer undo. Except for in one scenario which I will explain.
I have quite a few extensions install but I can make this issue go away if I disable Brackets Git.
This extension shows you a red or green bar to the left of the line numbers indicating what has been added or removed from the branch's version of the file.
If I disable Brackets Git, I can save and undo to my hearts content, now I have not tested this thoroughly because I use Brackets Git constantly and have just dealt with the not being able to undo issue (even though its very frustrating). However, any time I've disabled it I've not run across this issue.
Hope this helps!! Good luck!
I can confirm this bug on Windows 10 for Release 1.5 build 1.5.0-16538 (release cf9cf4698)
Only started to happen today, worked fine yesterday. Weird.
Working on a small project ( 1.5MB ) in .html / .php / .css / .js files. Extensions: Emmet and Extract for Brackets. Disabling the extensions has no effect.
Going to Debug > New Brackets Window and working in the new window seems to fix the bug.
Good luck!
The same issue. LinuxMint 17.3 Rosa.
Can someone sum up what is definitively known about the issue at this point?
This editor is great -- it can't be brought down by this bug.
It all smells like a typical "spooky action at a distance" antpattern to me. The authors seem unable to state what exactly can cause the undo history to be reset, and the apparent causes seem totally random at this point.
What Brackets needs, is smaller and more frequent updates, to make it easier to diff between them and track down who changed what to have caused issues quite as deep as this one.
I just ran few more passes with my extension and I still have no good idea what is going on. Either the issue has existed from 1.0 (at least) or my method of corrupting the history is faulty (the next save occurs before the previous one happens, which I am not sure why it could be happening when CommandManager.execute returns a promise that gets resolved when the save is complete.
And even today (3 month later), I the autor have no idea how it happens, it seems totally random, and my initial thought of "large files" doesn't seem to hold either.
@thany @petetnt I thought it was at least understood that the issue occurs when something (including a brackets extension) modifies or even 'touches' the active file. Has anyone at least worked down to the undo mechanism in the brackets source?
@arctwelve I don't think it has anything with the undo per se, but something happening to the file during, after or just before saving the file, which invalidates the history and starts it again, effectively destroying the undo (and redo) mechanisms in the process.
If I had to guess, it's some sort of race condition with saving the file and updating the CodeMirror history (which I already dug into last time I was checking on this early 2016, but couldn't really find anything useful). I thought that my corrupt-brackets-history
would be the key, but like I said, the same happens up until 1.0
and even earlier sprints, rendering either the extension or bisecting useless.
@petetnt It looks like active files are watched by Brackets. For example, if you make a change to a saved open file in Brackets with another editor (and save it) then the changes are immediately reflected in Brackets. Other editors will prompt you with an external modification warning. If you accept the external changes in, say, TextPad, the undo history is lost, which seems normal.
But even doing a touch on a file open in Brackets will cause the undo history to be lost. The way Brackets interprets whether a file has been externally altered needs to be updated.
@arctwelve I think we debunked file watching itself on another issue related to this (file watchers never touch the files) but I have a new theory which applies to at least why my extension is failing:
When CommandManager.execute
is called with Commands.FILE_SAVE
(or any other SAVE related method) the function returns a $.Deferred
promise that resolves when file saving succeeds (or fails). The edit: there are safeguards in place in DocumentCommandHandlers... execute
calls (or the doSave
-methods from DocumentCommandHandlers.js
) aren't, however, queued or debounced in any way, making it possible to have an race condition where two (or more) COMMAND.FILE_SAVE
s are called very close to each other (within milliseconds) which resolve when they are ready: the latter potentially resolving before the former.
At this point CodeMirror could confuse the File History and just start it from the scratch. That explanation would explain why:
~- Removing the timeout in my extension makes it occur more frequently (almost always)~
Like Node docs say (https://nodejs.org/docs/v0.10.0/api/fs.html#fs_fs_write_fd_buffer_offset_length_position_callback)
file.write
... Note that it is unsafe to use fs.write multiple times on the same file without waiting for the callback. For this scenario, fs.createWriteStream is strongly recommended.
We do wait for the callback usually, but that doesn't stop us from calling fs.write
on the same time multiple files as currently there seems to be no mechanisms to block this.
//cc @swmitra @abose @nethip Do correct me if I am wrong
@petetnt - try 'touching' a file you're working on in Brackets. The history is lost.
@arctwelve I know, it's not related to this particular issue though (losing history after saving). I have an another extension called brackets-persistent-history with can persist your history over project switches, closing of Brackets and external changes.
@petetnt aha...hmm. ok. That's confusing since It seems like there's some cross-over in this thread with the general issue of losing history if an external file is modified (e.g., usually by an extension) and losing history after saving. In my case history is always lost after a file is saved because it's in the saved state when the file is vulnerable to silent external modification. If a brackets file is just saved, it can be modified by an external process without warning: this is a problem. An unsaved file will warn the user, oddly enough.
Anyway, I'm not able to produce any working behavior with the extension you recommended, Is there a test case that should show it's working? Is it always on once installed?
@arctwelve Which extension, the corrupt one or the persist one? The corrupt one can be run from File -> Try to corrupt
. The persistent one is always on, and you can test it by opening Brackets with file foo.js
, doing changes, saving, closing Brackets, opening Brackets and pressing CTRL+Z.
It most likely won't help against this particular issue though because the history is nulled anyways (so the cached history will also be null).
Which extension is always nuking your file history? Anyway, this issue about the bug where saving nukes the file history, not about external processes nuking the file history.
Just to chime in with some of my experiences. I've said before that it happens with all file types, but now I can confirm it is only with css files.
Also, a few times I got a warning message in Brackets saying that the file has been modified outside of the editor(should I keep the changes and that stuff).
But the file hasn't been modified anywhere, there were no other editors opened that might have caused that.
@Madebym are your CSS files compiled (from say SASS or LESS files)?
@petetnt Nope, pure CSS.
I can give it a go with scss files later today. Will let you know.
I have also seen this message, when pressing Ctrl+S quickly many times.
@Madebym No need, but if you could provide an CSS file that causes you this kind of issues that would be helpful.
@valtlait Yup, it's something that might happen due to what I described on https://github.com/adobe/brackets/issues/11826#issuecomment-172765439: for why the message doesn't always pop up might be for the same exact reason: race condition with the stat
timestamps
@petetnt Just happened now again. No other editor(like Notepad++ opened or similar).
css/styles.css has been modified on disk outside of Brackets, but also has unsaved changes in Brackets. Which version do you want to keep.
You want me to paste the whole CSS file here?
@Madebym Maybe create a gist of it (gist.github.com) and paste the link here.
Can you also tell me your operating system (and some hardware information, particularly is your harddrive an HDD or an SSD)
@petetnt Ok, here is the gist: https://gist.github.com/Madebym/aa8a5f300d22eaacf61c
Operating system is Win7 Ultimate Service Pack 1, hard-drive is a very old HDD :)
I also have a Win10 on my laptop, I will copy the same exact project there and see how it behaves. But I know that same issues were also there when I use my laptop for development.
Tried to debug this again yesterday for couple of hours with this comment in mind but everything was pretty much a dead end, so one can pretty safely rule out file I/O.
Going through the stack of my corrupting extension I am currently looking into this particular CodeMirror function: https://github.com/codemirror/CodeMirror/blob/master/lib/codemirror.js#L7919
Just when the corruption happens this function gets called twice with the same change
object.
For example if the corruption happens on the 16th try, we get two consecutive change
objects where the text content is Try 15
and Try 15
. However, the editor itself has correctly been updated to Try 16
. Similarly the opId
gets incremented by 3 instead of 1 like it does normally between the operations. This could be totally meaningless though, as It's hard to say if this happens because the history got corrupted or because the editor loses focus for a while when it triggers the debugger. Sam
ATTN those who have this particular issue:
I just ran preliminary tests with 1.6. shell and latest master and it seems that I am not able to reproduce this anymore.
Hi, I updated to 1.6 today, and found that I had this issue. It seems to work (I can undo after a save) but after multiple repeats of the action (type, save, undo), it stops working.
Windows 10 Brackets 1.6 rotary HDD No extensions installed
Out of curiosity, why has a new version been released when a bug as huge as this one has not yet been confirmed to be solved? Personally I find this worrisome.
@thany it's a tough call. A minor version release doesn't demand that every bug be fixed, but it's sad to see a bug this serious still not fixed.
There's no way of reverting a change that was made if the file was saved. I don't know if that's a feature (saved=saved), but it's really annoying, especially when working with git. I had to reinstall 1.4 because of that, I cannot do any work without my "undo"^^
Windows 10 x86_64 Ubuntu 15.10 x64
EDIT: november 1st, 2016 : TL&DR; check out https://github.com/adobe/brackets/issues/11826#issuecomment-257429242