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.
Created attachment 162814 [details] example ui.xml file that will freeze the ide When opening an xml file (for a gwt project) it seems the Event Dispatch Thread freezes up - when resizing the window no repaint is done. I can open my pom and some other xml files, so its not ALL xml files - just most of my gwt ui binder files. One of these files is attached. This were working in the build from october 17, but not this current build from today nov. 7th.
Created attachment 162815 [details] messages.log
Created attachment 162927 [details] Threaddump I still experience the problem in a newer build.. 2016-11-14 Took a threaddump.
Please try again with some recent build
Created attachment 163000 [details] messages.log Messages.log from new build (Build 201611230001)
Created attachment 163001 [details] Threaddump Threaddump from (Build 201611230001)
Is it still the same ui.xml ? The threaddump shows exactly the code which have been fixed (and the fix made it into the build for sure). I've opened ui.xml (success( and tried to invoke completion at various places (success). your threaddump shows stuck breadcrumbs during its initialization.
Created attachment 163003 [details] Thread dump Sorry - i will attach a new ui.xml file. I just tried again, and in this threaddump, the AWT-EventQueue-0 is in org.netbeans.api.lexer.TokenSequence.isInvalid
Created attachment 163004 [details] ui.xml file that freezes the ide
Strange; still no luck. Yes, TokenSequence.isInvalid is on the top, but the main suspect is the XMLSyntaxSupport a few frames below, which I reimplemented at the beginning of November. How exactly do you work with the file - say you open a folder with the file in the project view. Then - what ? I'm asking because when I open the file (doubleclick, Open command), the Breadcrumb initializes (stack similar to your threaddump) but execution does not even go into the loop indicated by your threaddump. I can see a possible defect in the source, but I'd like to verify that it actually addresses your case.
It dosnt seem to change anything how i open the file. I recorded a video of what happens when i search for the file and opens it up - you can see that after the editor show the file, everything stop responding (see the small cog turning in the search panel). https://www.youtube.com/watch?v=lIN1D6-ZG8Y
(In reply to akobberup from comment #4) > Messages.log from new build (Build 201611230001) This is strange - did you install a fresh build, or auto-updated: there are mixed versions of modules shown in the log: org.netbeans.modules.xml.catalog/2 [3.5.0.4 4 nbms-and-javadoc-663-on-20161110] vs. org.netbeans.modules.project.ant/1 [1.67 201611230001] The module supposedly containing the fix is org.netbeans.modules.xml.text/2 [1.60.0.1 1 nbms-and-javadoc-663-on-20161110] that seems before the fix made it into the downloadable build.
I installed a new nb from the website - but i did not delete my old userdir when uninstaling (i hate to loose all my codetemplates, altered keymaps ect.) I can try to export my options to a file and do a complete uninstall and reinstall to see if that will help..
I installed newest build after removing all old nb installations, and that solved the issue. So i guess i will need to revise my "update-to-a-new-dev-build" procedure, even though it makes it hard to revert to the previous build, if it turns up that the new build is broken (happens sometimes that for example a blocker bug is killing the editor). Thanks for the help and patience :)
Spec / impl versions of modules are rarely updated after "normal" bugfixes, so autoupdate may not pick up a module even though there was a change in its code. The module will update, eventually, after some change which demands version increase.