Comment 1 Thomas M??der 2004-05-10 04:39:34 EDT

This is in the pagebook view. Moving to platform-ui

Comment 2 Nick Edgar 2004-05-10 11:12:46 EDT

I've added a null check, but I was not able to reproduce the case where
book==null.  

Michael, do you have steps to reproduce this?
I tried:
- in resource perspective,
- open search view
- shutdown/restart

Comment 3 Michael Fraenkel 2004-05-10 13:00:56 EDT

It would have been the Java Perspective but I cannot imagine that being the 
problem.
I also had two searches with content.
I will see if I can recreate the problem.

Comment 4 Nick Edgar 2004-05-13 22:57:01 EDT

I've seen other cases where views have not been properly created before a
setFocus() or dispose() comes in.

For example, the following occurred on I20040513-1200:

!ENTRY org.eclipse.ui 4 4 May 13, 2004 14:09:00.279
!MESSAGE Category org.eclipse.swt.sleak not found for view
org.eclipse.swt.sleak.views.SleakView.  This view added to 'Other' category.
!ENTRY org.eclipse.core.runtime 4 2 May 13, 2004 14:09:05.697
!MESSAGE Problems occurred when invoking code from plug-in:
"org.eclipse.core.runtime".
!STACK 0
java.lang.NullPointerException
	at
org.eclipse.ui.views.navigator.ResourceNavigator.setFocus(ResourceNavigator.java:1057)
	at org.eclipse.ui.internal.WorkbenchPage$2.run(WorkbenchPage.java:469)
	at
org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:607)
	at org.eclipse.core.runtime.Platform.run(Platform.java:668)
	at org.eclipse.ui.internal.WorkbenchPage.activatePart(WorkbenchPage.java:466)
	at org.eclipse.ui.internal.WorkbenchPage.onActivate(WorkbenchPage.java:1991)
	at org.eclipse.ui.internal.WorkbenchWindow$7.run(WorkbenchWindow.java:1910)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69)
	at org.eclipse.ui.internal.WorkbenchWindow.setActivePage(WorkbenchWindow.java:1897)
	at org.eclipse.ui.internal.WorkbenchWindow.restoreState(WorkbenchWindow.java:1465)
	at org.eclipse.ui.internal.Workbench.restoreState(Workbench.java:1206)
	at org.eclipse.ui.internal.Workbench.access$10(Workbench.java:1173)
	at org.eclipse.ui.internal.Workbench$13.run(Workbench.java:1084)
	at
org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:607)
	at org.eclipse.core.runtime.Platform.run(Platform.java:668)
	at org.eclipse.ui.internal.Workbench.restoreState(Workbench.java:1017)
	at
org.eclipse.ui.internal.WorkbenchConfigurer.restoreState(WorkbenchConfigurer.java:167)
	at
org.eclipse.ui.application.WorkbenchAdvisor.openWindows(WorkbenchAdvisor.java:648)
	at org.eclipse.ui.internal.Workbench.init(Workbench.java:807)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1301)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:243)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:141)
	at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:90)
	at
org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:298)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:249)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:126)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at org.eclipse.core.launcher.Main.basicRun(Main.java:269)
	at org.eclipse.core.launcher.Main.run(Main.java:722)
	at org.eclipse.core.launcher.Main.main(Main.java:706)
!ENTRY org.eclipse.core.runtime 4 2 May 13, 2004 14:23:40.94
!MESSAGE Problems occurred when invoking code from plug-in:
"org.eclipse.core.runtime".
!STACK 0
java.lang.NullPointerException
	at
org.eclipse.ui.views.navigator.ResourceNavigator.dispose(ResourceNavigator.java:414)
	at
org.eclipse.ui.internal.WorkbenchPartReference.dispose(WorkbenchPartReference.java:162)
	at org.eclipse.ui.internal.ViewFactory$ViewReference.dispose(ViewFactory.java:73)
	at org.eclipse.ui.internal.WorkbenchPage$6.run(WorkbenchPage.java:1189)
	at
org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:607)
	at org.eclipse.core.runtime.Platform.run(Platform.java:668)
	at org.eclipse.ui.internal.WorkbenchPage.dispose(WorkbenchPage.java:1187)
	at org.eclipse.ui.internal.WorkbenchWindow.closeAllPages(WorkbenchWindow.java:588)
	at org.eclipse.ui.internal.WorkbenchWindow.hardClose(WorkbenchWindow.java:1066)
	at org.eclipse.ui.internal.WorkbenchWindow.busyClose(WorkbenchWindow.java:485)
	at org.eclipse.ui.internal.WorkbenchWindow.access$0(WorkbenchWindow.java:467)
	at org.eclipse.ui.internal.WorkbenchWindow$1.run(WorkbenchWindow.java:555)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69)
	at org.eclipse.ui.internal.WorkbenchWindow.close(WorkbenchWindow.java:553)
	at org.eclipse.jface.window.WindowManager.close(WindowManager.java:101)
	at org.eclipse.ui.internal.Workbench$10.run(Workbench.java:450)
	at
org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:607)
	at org.eclipse.core.runtime.Platform.run(Platform.java:668)
	at org.eclipse.ui.internal.Workbench.busyClose(Workbench.java:447)
	at org.eclipse.ui.internal.Workbench.access$8(Workbench.java:389)
	at org.eclipse.ui.internal.Workbench$12.run(Workbench.java:561)
	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69)
	at org.eclipse.ui.internal.Workbench.close(Workbench.java:559)
	at org.eclipse.ui.internal.Workbench.close(Workbench.java:535)
	at org.eclipse.ui.internal.QuitAction.run(QuitAction.java:55)
	at org.eclipse.jface.action.Action.runWithEvent(Action.java:881)
	at
org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:899)
	at
org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:850)
	at
org.eclipse.jface.action.ActionContributionItem$7.handleEvent(ActionContributionItem.java:769)
	at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82)
	at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:796)
	at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:2725)
	at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2390)
	at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1353)
	at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1324)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:243)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:141)
	at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:90)
	at
org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:298)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:249)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:126)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at org.eclipse.core.launcher.Main.basicRun(Main.java:269)
	at org.eclipse.core.launcher.Main.run(Main.java:722)
	at org.eclipse.core.launcher.Main.main(Main.java:706)

The stacks above can only occur if the part's controls have not been created.

The lifecycle should always be:
- init
- createPartControl
- setFocus (optional)
- dispose()

I haven't been able to come up with a reproduceable case for this.

Stefan, have you seen anything like this lately?

Comment 5 Nick Edgar 2004-05-13 23:50:51 EDT

A view's createPartControl method is called only from ViewPane.createChildControl.
This is called from ViewPane.createControl, and also from
ViewFactory.busyRestoreView, which is where the view part gets instantiated.
However, ViewPane.createChildControl can be a no-op if the pane's control has
not been created yet.

I can't see how we would get in this state though.

PartStack.createControl now always calls refreshPresentationSelection, which
calls createControl on the current pane, causing createChildControl to be called
as well.

It's possible that the problem here has been fixed in the last couple of days
due to changes for bug 61913 and bug 61581.

Comment 6 Nick Edgar 2004-05-13 23:51:51 EDT

Moving to Stefan for comment.

Michael, if you have any hints on how to reproduce this, that would help us
determine whether the problem still exists or has already been fixed.

Comment 7 Michael Fraenkel 2004-05-14 09:12:18 EDT

I haven't seen the problem again.  We can probably close this and I will 
reopen it if I come across this problem or a way to reproduce it.

Comment 8 Tod Creasey 2004-05-14 16:34:28 EDT

Closing as requested

Comment 9 Nick Edgar 2004-05-17 16:07:27 EDT

*** Bug 62444 has been marked as a duplicate of this bug. ***

Comment 10 Nick Edgar 2004-05-17 16:07:49 EDT

Still happening on I20040514.

Comment 11 Dirk Baeumer 2004-05-18 05:05:59 EDT

Nick I have uploaded my workspace to our ftp server. Will sent you the address 
by mail.

Comment 12 Nick Edgar 2004-05-19 01:16:13 EDT

Reproduced the problem using Dirk's test workspace (thanks Dirk).

While restoring the workbench state, ViewFactory.busyRestoreView instantiates
the package explorer and tries to create its control via
ViewPane.createChildControl().  However, the ViewPane's controls themselves have
not been created yet (nor has its container been set), so this is a no-op.

Later, when setFocus is called on the package explorer, neither its controls nor
its pane's control have been created, although the pane does know its container
at this point.

Comment 13 Nick Edgar 2004-05-19 02:37:17 EDT

Simplified steps to reproduce this:
- new workspace
- close intro
- in initial resource perspective, drag Outline over Navigator
- drag Navigator to be in the left position (in the same folder)
- then drag it back to the right position (in the same folder)
- (Navigator is active)
- exit
- restart
- get NPE in ResourceNavigator.setFocus() because its viewer is not created

The dragging is necessary to get the Navigator to appear in a position other
than the first in the <folder> element in the workbench.xml.

Comment 14 Nick Edgar 2004-05-19 03:05:07 EDT

The problem is caused by updateContainerVisibleTab().
While replacing the Outline's placeholder with the ViewPane, it ends up changing
the current part to be the first part in the folder: the Outline. 
refreshPresentationSelection then materializes the Outline's controls, but not
the Navigator's.  However, the WorkbenchPage.restoreState method still thinks
the Navigator is the active part.  When it tries to make it active, setFocus
fails because its control has not been created.

This is easy to see if you set a modification watchpoint on PartPane.current.

The commented out (child == current) check in PartStack.remove(LayoutPart) would
have prevented this.  The comment is unclear as to what other problems it's
preventing, so I'm leaving it alone for now.

Comment 15 Nick Edgar 2004-05-19 16:50:40 EDT

Fixed by forcing the pane's and part's controls to be created in
ViewFactory.busyRestoreState.

There's still a problem with refreshPresentationSelection being called when a
part other than the selected one is being removed, but that no longer causes
parts to be left in a partially created state.
Stefan is looking into this issue.

Comment 16 Nick Edgar 2004-05-19 16:52:20 EDT

Fix released.

Comment 17 Kim Horne 2004-05-21 10:24:20 EDT

Verified using Nicks steps in 200405210010.

Comment 18 Ines Khelifi 2004-05-21 10:42:07 EDT

Verified with build id Build id: 200405210800 on Windows XP and Mac OS 10.3.3
(using steps from comment #13).

Comment 19 Stefan Xenos 2004-05-26 19:41:50 EDT

Note: the problem with refreshPresentationSelection has also been fixed.

Comment 20 Nick Edgar 2004-06-29 10:10:35 EDT

*** Bug 63299 has been marked as a duplicate of this bug. ***

Comment 21 Randy Hudson 2004-07-02 13:11:27 EDT

Regarding comment 4, createPartControl() is optionally called according to the 
API.  So it is only called if the part is made visible.  In fact, I recall my 
editor being disposed without it's control ever being created.  Has this 
changed in 3.0 such that it is now supposed to be guaranteed?

Comment 22 Nick Edgar 2004-07-05 12:30:21 EDT

Although IWorkbenchPart.createPartControl does state:
 * <p>
 * An important point to note about this lifecycle is that following 
 * a call to init, createControl may never be called. Thus in the dispose
 * method, implementors must not assume controls were created.
 * </p>

I can't think of any cases where this would actually happen.
Randy, do you have a case where this happened in 2.1?
In 3.0, we try to ensure that if the part is instantiated, then its controls are
created too (we also try to ensure that a part is only instantiated if its
controls are neeeded).

Comment 23 Randy Hudson 2004-07-06 10:41:14 EDT

In 2.1, or maybe it was 2.0, if you restore a workbench with an editor opened 
in the background, and you never bring it to the foreground, createPartControl 
was never called.

Comment 24 Nick Edgar 2004-07-06 15:05:26 EDT

In this case, the editor (or view) should not even be instantiated.

Comment 25 Randy Hudson 2004-07-07 10:21:23 EDT

> In this case, the editor (or view) should not even be instantiated.

How would the editor indicate its dirty state if it has not been instantiated?  
It seems like it has to be instantiated for this to work correctly.

Comment 26 Nick Edgar 2004-07-07 12:39:43 EDT

Dirty editors are not persisted between sessions.  You would have to activate
the editor first in order to dirty it.

Comment 27 Randy Hudson 2004-07-08 10:44:56 EDT

The editor can become dirty because its document was edited in another 
WorkbenchWindow, or within the same window when there are editors which work 
with multiple resources and a "realized" editors has touched a resource also 
used by one of the not-yet-shown editors.

Comment 28 Nick Edgar 2004-07-19 13:00:20 EDT

That case is a problem currently.  I've filed bug 70363 for this.