Bugzilla – Full Text Bug Listing
| Summary: | [Workbench] Ctrl-tab in maximized editor causes NullPointerException | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Mike Hinchey <hincheymg> | ||||||
| Component: | UI | Assignee: | Michael Van Meekeren <michaelvanmeekeren> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P2 | CC: | eclipse, ines, sxenos | ||||||
| Version: | 3.0 | ||||||||
| Target Milestone: | 3.0 RC2 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Mike Hinchey
Another detail to reproduce: maximize the editor before trying ctrl-tab. can not recreate. Is there an error in your editor happening as well? Is there more in the log? Ok, I was able to reproduce this bug using M9. Here are my steps: - Start eclipse with open editors - Go to "Window->Preferences..." - Select "Workbench"->"Keys" - Add "Ctrl+Tab" as a key binding to the "Window" category and "Next Editor" command name. - Maximize the editor pane (double click on an editor) - Press "Ctrl+Tab" The "Error Executing Command" dialog shows up. The content of the log file is below. This is a reproducible bug. !ENTRY org.eclipse.ui 4 4 May 27, 2004 11:47:16.489 !MESSAGE The command for the key you pressed failed !ENTRY org.eclipse.ui 4 0 May 27, 2004 11:47:16.499 !MESSAGE The command for the key you pressed failed !STACK 0 java.lang.NullPointerException at org.eclipse.ui.internal.PerspectiveHelper.partChangeAffectsZoom(PerspectiveHelper.java:1002) at org.eclipse.ui.internal.WorkbenchPage.partChangeAffectsZoom(WorkbenchPage.java:2232) at org.eclipse.ui.internal.WorkbenchPage.activate(WorkbenchPage.java:446) at org.eclipse.ui.internal.CyclePartAction.activate(CyclePartAction.java:99) at org.eclipse.ui.internal.CyclePartAction.runWithEvent(CyclePartAction.java:487) at org.eclipse.ui.commands.ActionHandler.execute(ActionHandler.java:141) at org.eclipse.ui.internal.commands.Command.execute(Command.java:132) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.executeCommand(WorkbenchKeyboard.java:469) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.press(WorkbenchKeyboard.java:887) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.processKeyEvent(WorkbenchKeyboard.java:928) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.filterKeySequenceBindings(WorkbenchKeyboard.java:546) at org.eclipse.ui.internal.keys.WorkbenchKeyboard.access$2(WorkbenchKeyboard.java:494) at org.eclipse.ui.internal.keys.WorkbenchKeyboard$1.handleEvent(WorkbenchKeyboard.java:259) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Display.filterEvent(Display.java:712) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:795) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:820) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:805) at org.eclipse.swt.widgets.Control.traverse(Control.java:2704) at org.eclipse.swt.widgets.Control.translateTraversal(Control.java:2685) at org.eclipse.swt.widgets.Composite.translateTraversal(Composite.java:553) at org.eclipse.swt.widgets.Display.translateTraversal(Display.java:3153) at org.eclipse.swt.widgets.Display.filterMessage(Display.java:726) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2378) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1363) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1334) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:253) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:141) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:97) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:307) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:256) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:127) 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:185) at org.eclipse.core.launcher.Main.run(Main.java:638) at org.eclipse.core.launcher.Main.main(Main.java:622) To avoid changing the key preferences, you can alternatively use CTRL+F6 (default key binding for next editor). It yields to the same result as described in comment #3. I am using Build id 200405270800 and I can reproduce this problem. Currently investigating… Created attachment 11229 [details] Patch to solve NPE problem After discussing with Stefan, he pointed me to a fix that Nick applied for views (turns out to be a similar problem as this one: Bug 61545 - comment #15). It seems to fix the current problem. Please comment if the NPE still occurs or other problems arise. The only other issue with the patch above is the following line in the
EditorManager:
"ref.getPane().createControl(page.getClientComposite());"
After briefly discussing with Nick, he pointed out that he is not sure if the
editor pane's controls are parented under the same composite as views (the
workbench page's client composite).
I tried this instead (since Stefan suggested that the editor's pane's controls
are parented under the EditorSashContainer):
"EditorStack wb = ((EditorPane) ref.getPane()).getWorkbook();
EditorSashContainer ea = wb.getEditorArea();
ref.getPane().createControl(ea.getParent());"
The above alternative did not work since the composite itself
("ea.getParent()") is null when the pane's control is null. I am not sure how to
otbain a composite (that's not null) using “EditorSashContainer” to pass to the
"createControl" method.
stefan, any suggestions for ines' last comment? Created attachment 11536 [details]
Patch for Ctrl+Tab NPE
With Stefan, added the following:
- "createControl()" call to the "EditorAreaHelper" constructor.
- "createControl()" call to "EditorManager#busyRestoreEditor()".
- A check to ensure that the child controls are only created once in
"PartPane#createChildControl()".
- Null checks for "root" in "PartSashContainer".
need to verify that we are not defeating the editor reference support to avoid initializing unseen editors. Ines can you help write a test for this? committed fix to HEAD, Ines will try to find a way to verify that EditorReferences are still working marking as fixed I have created Bug 66065 to track the verification of this bug. I am not sure if this bug should be re-opened or not, but I found a regression (comparing to M9). I wrote some tests to validate this patch (Bug 66065). One of the tests does the following (I ran it on build id 200406090800): - Create 10 text files (file1.txt to file10.txt) - Open file1.txt through file10.txt - Restart the workbench - The test ensures that only the visible file's part should have been created. In this case file1.txt through file file9.txt's parts should be null, and file10.txt's part should be created (since it was the last active file before restart). However, the “asserts” show otherwise. The results show that file1.txt and file10.txt's parts are created, while the rest are null. My first guess was that the editors ordering on restart (there is an existing bug about this) might have an effect on this. To verify the latter theory, I ran the tests on M9 (where the editors ordering works fine) and they passed (the only failing test was “Ctrl+Tab”, which is normal). I then applied this patch to M9, which caused the tests to fail (same results as for build id 200406090800). By debugging through the code, it looks like the problem might be in "EditorAreaHelper#EditorAreaHelper(WorkbenchPage page)". To fix this bug, a "this.editorArea.createControl(page.getClientComposite())" was added to the constructor. The addition of that method call is causing some disturbance in the lazy creation of editors on start up. I have not yet figured out what exactly is causing this behavior. I know the source of the problem, but not the reasoning behind it. Verified with build id I20040609800 and I200406101200 on Windows XP. Adding Kim so that she can mark this bug as verified. Marking as verified on your behalf. |