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.
similar to issue #100752. It is not nice if we have editors that are very eager like XSD or some others in enterprise support. Static reference from org.netbeans.modules.editor.hints.HintsUI.INSTANCE (from class org.netbeans.modules.editor.hints.HintsUI) : --> org.netbeans.modules.editor.hints.HintsUI@0x6d2f6d00 (40 bytes) (field comp:) --> org.openide.text.QuietEditorPane@0x74734fa8 (451 bytes) (field parent:) --> javax.swing.JViewport@0x749e7718 (351 bytes) (field parent:) --> javax.swing.JScrollPane@0x749eb180 (369 bytes) (field parent:) --> javax.swing.JPanel@0x749e7580 (320 bytes) (field parent:) --> org.netbeans.modules.xml.schema.core.multiview.SchemaSourceMultiViewElement@0x74734e00 (415 bytes)
Should be fixed altogether with issue #100752.
*** Issue 102417 has been marked as a duplicate of this issue. ***
See #102417.
I sotrongly disagree that this is a P1 J1 stopper bug. If you have editor which consumes such a large amount of memory that it hurts the ide ix it on the proper place e.g. XSD.
Sorry I didnt realize that you made it P3 again.
Just for record. We will not fix this for M9. Reasons: 1) The fix might be risky 2) Memory consumption scales well from our point of view. No matter how many files user opens/closes just one is held. 3) Only happens when the user has all files closed. 4) If we fix this reference there still be several others. So there is no guarantee that the fix will help 5) It is not true that this issue blocks #98405. Even if we fix it the user will not be able to open more than one bigger XSD file or do any other action in the IDE e.g. open a project without potential getting OOME. So these bugs are unrelated. 6) Look at opening and closing other filetypes it woks well.
*** Issue 104549 has been marked as a duplicate of this issue. ***
*** Issue 105080 has been marked as a duplicate of this issue. ***
can we have fix for this before the beta?
Several things happened on this recently: -Petr Nejedly fixed issue #104461 (which should ensure that components are correctly unregistered from the old org.netbeans.editor.Registry even if the components are multiviews). -I have rewritten editor/hints and java/source to use EditorRegistry (which is a new API) Unfortunately, when all components are closed, an event is fired from the EditorRegistry, and EditorRegistry.lastFocusedComponent() still returns a component during processing of the event. So editor/hints and java/source hold the component (because they do not know the component is already closed). Possible solutions: -EditorRegistry could ensure that when all components are closed, an event is fired in such a way that ER.lFC() would return null during processing the event. I think that this would be the best option (it would be easy to write the listeners correctly). Mila promised he will try to modify EditorRegistry accordingly. -the clients could be rewritten to ER.focusedComponent() (which returns null during the last event processing), but I am not sure about what would be the impact of such a change (both performance and behavior). -rewrite the clients not to hold the component hard - might be relatively simple for editor/hints, but probably very difficult for java/source.
Can someone look at this?
Sorry, but I do not think this qualifies as a P2. As I wrote above, Mila will try to modify the EditorRegistry in such a way that "ER.lFC() == null" during the event thrown after closing the last editor pane, but I guess he unfortunately did not have spare cycles to actually do it yet.
*** Issue 85312 has been marked as a duplicate of this issue. ***
Mila, please can we have a fix for this at the earliest?
Ok, I'll do it. But I see no straightforward solution for checking when component is "closed" in the EditorRegistry. As a first attempt I would use AncestorListener.ancestorRemoved() but since this one is also fired when maximizing windows in our winsys I would combine it with a 2000ms timer started in ancestorRemoved() and if the component does not get re-added in 2000ms then I will fire the EditorRegistry listeners. If anyone know about better solution please speak up.
Honzo, I'm not sure whether you've meant originally that ("focusLost", null, null) would be fired (once there are no longer any registered components) or anything else?? For me it seemed cleaner to add an extra "lastFocusedRemoved" property that gets fired when last-focused-component gets removed from component hierarchy for >2000ms. So ("lastFocusedRemoved", removed-last-focused-component, current-focused-component) would get fired and you may check (evt.getNewValue() == null) if there are no more registered components. Let me know if you're ok with this or not. Thanks.
Created attachment 51384 [details] Patch adding "lastFocusedRemoved" property
*** Issue 123660 has been marked as a duplicate of this issue. ***
For hints and java/source, it should be enough if any event would come (hints and java/source do not check touch the event at all), and EditorRegistry.lastFocusedComponent() would return null at that time. It should clear the references.
*** Issue 123857 has been marked as a duplicate of this issue. ***
*** Issue 124715 has been marked as a duplicate of this issue. ***
I was trying to test this with the wsdleditor. I got a NPE and a AssertionError. To reproduce NPE: 1. Open a wsdl document in wsdl editor, after the given (initial) patch is applied. 2. NPE is thrown from CompletionProvider To reproduce Assertion Error: 1.Once NPE is fixed. Open wsdl document. 2.Go to source view. 3.AssertionError is thrown. I tried to patch it. But my knowledge of the editor code is zero. I will attach the patch. Please review and make appropriate changes. Unfortunately, I did not backup the log files. Let me know if you need it.
Created attachment 54786 [details] CompletionProvider NPE patch
Created attachment 54787 [details] EditorRegistry assertionerror patch
Thanks for the patch improvement. I'm still working on the final patch since the original thought with the ancestor does not work well for NB tabbed container that does add/removeNotify() for all the (editor) tabs except the one that is focused. So the solution must be more complex because the unfocused editor panes still need to be members of the EditorRegistry (due to proper function of WordMatch etc.). I expect to integrate the final fix during this week.
I have a final fix. I have also patched the CompletionImpl. Added API keyword since new property EditorRegistry.LAST_FOCUSED_REMOVED_PROPERTY was added. Since clients like java do not check for the property name specifically (they just recall ER.lastFocusedComponent() upon propertyChange()) there should be no further changes of clients necessary. Checking in src/org/netbeans/modules/editor/EditorModule.java; /cvs/editor/src/org/netbeans/modules/editor/EditorModule.java,v <-- EditorModule.java new revision: 1.129; previous revision: 1.128 done Checking in nbproject/project.xml; /cvs/editor/nbproject/project.xml,v <-- project.xml new revision: 1.39; previous revision: 1.38 done Checking in lib2/src/org/netbeans/api/editor/EditorRegistry.java; /cvs/editor/lib2/src/org/netbeans/api/editor/EditorRegistry.java,v <-- EditorRegistry.java new revision: 1.4; previous revision: 1.3 done Checking in lib2/src/org/netbeans/modules/editor/lib2/EditorApiPackageAccessor.java; /cvs/editor/lib2/src/org/netbeans/modules/editor/lib2/EditorApiPackageAccessor.java,v <-- EditorApiPackageAccessor.java new revision: 1.3; previous revision: 1.2 done Checking in completion/src/org/netbeans/modules/editor/completion/CompletionImpl.java; /cvs/editor/completion/src/org/netbeans/modules/editor/completion/CompletionImpl.java,v <-- CompletionImpl.java new revision: 1.91; previous revision: 1.90
Should not you write a test for this new very important behavior (whatever it is)?
Right, I have added a test. Checking in EditorRegistryTest.java; /cvs/editor/lib2/test/unit/src/org/netbeans/api/editor/EditorRegistryTest.java,v <-- EditorRegistryTest.java new revision: 1.3; previous revision: 1.2
This fix does not seem to fix one of the issues marked as a duplicate (Issue 123857). When testing with visual web, the TopComponent for the designer is still held from the JavaSource.binding field until another editor is opened.
The JavaSource.editorRegistryListener field is still holding onto the last editor in the case of visualweb. To reproduce: 1) Create a web project w/ visual web framework 2) Switch Page1 to JSP tab 3) Close page and project. The TopComponent for the designer is still held in memory, shown below: org.netbeans.modules.visualweb.designer.jsf.ui.JsfTopComponent[Visual Design,0,0,1014x958,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=448,maximumSize=,minimumSize=,preferredSize=]: private static final org.netbeans.napi.gsfret.source.Source$EditorRegistryListener org.netbeans.napi.gsfret.source.Source.editorRegistryListener-> org.netbeans.napi.gsfret.source.Source$EditorRegistryListener@1412262-lastEditor-> org.openide.text.QuietEditorPane@1d65df9-ui-> org.netbeans.editor.BaseTextUI@fa24f9-editorUI-> org.netbeans.modules.editor.NbEditorUI@9a442-toolBarComponent-> org.netbeans.modules.editor.NbEditorToolBar@4f9c0c-component-> [Ljava.awt.Component;@175873c-[10]-> org.openide.awt.Actions$ToolbarButton@1c36cea-listenerList-> javax.swing.event.EventListenerList@186f93c-listenerList-> [Ljava.lang.Object;@19d374c-[3]-> org.openide.util.actions.NodeAction$DelegateAction@10d669a-result-> org.openide.util.lookup.ProxyLookup$R@939432-data-> org.openide.util.lookup.ProxyLookup$SingleInternalData@1e6c1dd-lookups-> [Lorg.openide.util.Lookup;@1fc5167-[0]-> org.openide.windows.DefaultTopComponentLookup@13ea6bf-tc-> org.netbeans.modules.visualweb.project.jsfloader.JsfJspEditorSupport$JspEditorTopComponent@934cf4-parent-> javax.swing.JPanel@8165b3-component-> [Ljava.awt.Component;@e79817-[0]-> org.netbeans.modules.visualweb.designer.jsf.ui.JsfTopComponent@c64a78
I believe the last report is in fact caused by issue 129435