| Summary: | Infinite loop opening an editor after an exception in the editor. | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Michael Van Meekeren <michaelvanmeekeren> |
| Component: | UI | Assignee: | Hanna Farah <farahtech2002> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | major | ||
| Priority: | P2 | CC: | douglas.pollock, n.a.edgar, sxenos |
| Version: | 3.0 | Keywords: | helpwanted |
| Target Milestone: | 3.0 M9 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Michael Van Meekeren
Michael and I tried using the org.eclipse.ui.examples.multipageeditor example to re-produce this bug but it could not be re-produced. We introduced exceptions at various places (constructor, saving, switching pages) but they were caught and handled properly, not causing any infinite loops. When looking at the stack trace and the code, in ApplicationWindow.run, we get the current control that has focus, do some work, return focus to the previous control by calling setFocus which causes an EditorPane to requestActivation; the internalInit method in AbstractTextEditor will then call ApplicationWindow.run and we'll be in the loop. What was the focus control before the run? If it was the editor, then it should have already been fully initialized. ApplicationWindow.run should be changed to use forceFocus instead of setFocus. I've released the forceFocus change in ApplicationWindow.run. There was a change to ApplicationWindow at May 19, 9:19 p.m. It claimed to be fixing this bug. Is that true? Hanna, can you please verify whether the forceFocus change fixed the problem? As I mentionned in comment #1, this bug was only encountered once and could not be reproduced using the multi-page editor example. Nick's comment in his change (setFocus to forceFocus) makes sense for preventing this bug from occuring. |