Community
Participate
Working Groups
I20050509-2010 * turn "activate debug view when breakpoint hit" on * reset view management settings * select to show views in the Java perspective * select "switch to associated perspective when application suspends" to NEVER Debug to a breakpoint, in the Java perspective > the debug view opens > the variables view opens > the breakpoint view opens Terminate the app > var view closes > breakpoints view closes Debug to a breakpoint again > only the var view opens The breakpoints view should also auto-open. I found that by pressing "reset" on the view management page, it opened again. However, only on the first launch again. On subsequent launches, it did not appear.
After re-starting my workspace, I was unable to reproduce this problem.
.. and then it started happening again, so it appears to be a transient problem.
To me knowledge, our code in this area hasn't changed in a long time. And this is a common test case that should work fine. The last few times view management has broken it's turned out to be a problem with the platform's notification of view open/close events. So that's the first route I'd investigate.
When LaunchViewContextListener get the contextDisabled event, it turns off fIsTrackingPartChanges. This is done to ensure that views that are closed as a result of context disablement does not get added to viewIdsToNotOpen when the listener receives a perspective changed event. As a result of closing the views, LaunchViewContextListener gets contextEnabled events while it is still handling the disable event. At the end of contextEnabled, the listener loads the fIsTrackingPartChanges preference again. This overwrites fIsTrackingPartChanges set by #contextDisabled(...) accidentally and would turn this flag back on. In this case,when the variables view was closed by #contextDisabled(...), #contextEnabled(...) gets called as a result of closing the view. #contextEnabled(...) turns fIsTrackingPartChanges back on. When the breakpoints view is closed, because this flag is on, the view gets added to the list of views not to be opened automatically. As a result, the view would not get opened again in the next launch.
Fix included in patch from Bug 87586. The fix is in #contextEnabled(...) and #contextDisabled(...) from LaunchViewContextListener. Those methods will only turn fTrackingPartChanges off if the listener is currently tracking part changes. When the methods finish, the methods will only reload the setting from the preference store if it has changed the setting in the same method. The idea is that when #contextDiabled(...) turn fTrackingPartChanges off, #contextEnabled(...) will not set fTrackingPartChanges off because the setting is already off. When #contextEnabled(...) is completed, since it hasn't changed the flag, the method will not overwrite the setting. The setting will remain off until #contextDisabled(...) has finished closing all the views.
Will verify.
Applied patch from bug 87586.
Verified.
