Community
Participate
Working Groups
When a new BP is added, it is automatically selected in the breakpoints view. However the remove action on the BP toolbar does not get enabled after the new breakpoint is selected. Clicking on the new BP in the view causes the remove action to get enabled.
Feels like we should target this for 3.7, and if the fix is simple enough consider it for 3.6.1.
I feel kinda dumb. The problem is the focus in the view. When the view gains focus the action is enabled. The same is observed in Expressions view, but not in Seach view (for example). I'm not really sure if this is a valid bug.
I don't think we need to target this for 3.6.1.. however, since the "go to file" action enables I would also expect the "remove" action to enable in this case. We should also fix the issue in the expressions view.
(In reply to comment #3) > I don't think we need to target this for 3.6.1.. however, since the "go to > file" action enables I would also expect the "remove" action to enable in this > case. We should also fix the issue in the expressions view. Fair enough :-) I just checked in 3.5 and it is a regression.
(In reply to comment #4) > Fair enough :-) I just checked in 3.5 and it is a regression. Ok, I was assuming it was not a regression. Thanks for checking. We can decide whether to put this into 3.6.1 based on the size/risk of the fix.
No fix yet in 3.6.1. Both Breakpoints and Expressions views are still affected.
This is a good RC1 candidate, it *should* be a small change and is a regression from 3.6.x
(In reply to comment #7) > This is a good RC1 candidate, it *should* be a small change and is a regression > from 3.6.x Actually it's regression from 3.5.x :)
Created attachment 194394 [details] Proposed fix. Yes, this is a good quick fix candidate. The reason for the regression is that breakpoints view has a detail pane, and there is special management of the view selection provider to ensure that the detail pane key-bindings work properly on the detail pane selection. This small change, prevents the focus-lost event from removing the tree viewer as the selection provider for the view. If the focus is lost then gained by the detail pane, the detail pane will set a new selection provider anyway. However, if the focus is lost due to activation of another workbench part, the tree viewer will remain as the selection provider for the view, thus leaving the remove action enabled. This fix will not apply in the scenario where user sets focus in the detail pane, then switches to another part. In this case the detail pane will reset the selection provider to null when it loses focus. This is not a regression however as prior to 3.6, breakpoints view didn't have a detail pane. Also forcing the focus to return to the tree when the view is re-activated would not be consistent, so IMO it's better to live with this limitation. Mike, what do you think of this proposed fix?
I committed the proposed fix. We'll need to make sure to test the detail pane stuff in RC1. Mike, please review.
+1, the fix makes sense to me, I had no problem with any of the key bindings leaving the detail pane to reset its selection provider.
