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.
Product Version: NetBeans IDE Dev (Build 200809170201) Java: 1.6.0_10-rc; Java HotSpot(TM) Client VM 11.0-b13 System: Linux version 2.6.24-19-generic running on i386; UTF-8; en_US (nb) Userdir: /home/tester/Desktop/ud1 1. Have this code in a js file: function doSomethingHere() {} doSome(TYPE_CODE_COMPLETE_SHORTCUT_KEY) 2. Place caret behing doSome on the second line - doSome|(TYPE_...) 3. Press Ctrl+Space -> doSomethingHere is completed 4. Press Ctrl+Z -> result is following: function doSomethingHere() {} (TYPE_CODE_COMPLETE_SHORTCUT_KEY) -> expected result: function doSomethingHere() {} doSome(TYPE_CODE_COMPLETE_SHORTCUT_KEY)
Undo blocks are related to atomic locks. I wonder if this is related to the recent atomicLock changes in BaseDocument. I've seen some deprecation warnings; perhaps this is the excuse I needed to go through my modules and update all usages to see if it helps.
Fixed with changesets dc53f8ef45f9 and c18b65a8e302. The problem was that the code which inserts the completion item actually replaces the whole word (that's necessary because code completion sometimes changes the case - e.g. for case insensitive code completion), and the bug was that the code which replaces the code was not done under a single atomic operation (each atomic operation becomes an undoable event). So when you pressed Undo it deleted the whole word but if you would press Ctrl-Z again, you would get the original text - e.g. you saw the replacement as a delete followed by an insert. Should be fixed now.
I've backed out the fix (in changeset bf2440929342). Invoking the code template manager under a document write lock turned out to be risky and could cause deadlocks (see issue 147657).
The correct fix still cause a deadlock as Tor mentioned above.
Should be fixed in NB 7.1