Bug 308078 - [breakpoints] Breakpoint detail pane condition not applied until focus is changed from condition text box
Summary: [breakpoints] Breakpoint detail pane condition not applied until focus is cha...
Status: ASSIGNED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 3.6   Edit
Hardware: PC Windows XP
: P3 minor with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Dani Megert CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-05 11:12 EDT by Canna Wen CLA
Modified: 2022-08-30 17:07 EDT (History)
5 users (show)

See Also:


Attachments
patch (13.41 KB, patch)
2010-11-18 16:25 EST, Darin Wright CLA
no flags Details | Diff
patch (17.58 KB, patch)
2010-11-19 12:39 EST, Darin Wright CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Canna Wen CLA 2010-04-05 11:12:11 EDT
Build Identifier: Eclipse 3.6 M6 I20100312-1448

When you set a condition for a breakpoint, it does not get saved until you change the focus from out of the box. This may lead to confusion, as a breakpoint will appear to be conditional in the breakpoint view and on the editor marker, but it will just act as a normal breakpoint.

Reproducible: Always

Steps to Reproduce:
1. Set 2 breakpoints in a simple java program
2. Start a debug session
3. Set a false condition for the last breakpoint (ie. 1==2) and leave focus in the text area
4. Press run
5. Notice breakpoint is hit when it should not be
Comment 1 Darin Wright CLA 2010-04-05 17:34:30 EDT
This is working as designed. If you edit a condition you can save it using CTRL-S, or the save action in the file menu or toolbar (note the view shows it is dirty). Else, we auto save when you change focus, so the user does not lose work.
Comment 2 Markus Keller CLA 2010-06-01 08:59:38 EDT
> we auto save when you change focus

That would be fine, but that's not what I see with I20100527-1700:

- When I edit the condition and then give focus to another view or to an editor, the Breakpoints view stays dirty. Expected: Should auto-save, like when I click another UI element in the Breakpoints view

- When I edit the condition and then click the Debug button in the main toolbar, the condition eventually gets saved, but not before the target is launched, so it sometimes still uses the old condition when the breakpoint is hit the first time. To see that, set a breakpoint at the start of a main method, set condition to
    System.out.println("a"); return false;
, change "a" to "b", and then click Debug.
Comment 3 tavishf CLA 2010-09-30 21:56:54 EDT
Just wasted a whole bunch of time with this.  The only feedback that your changes to your breakpoint condition have not been saved is the little asterisk by the tab title, which I didn't notice.  Especially confusing since any other changes in that view are saved immediately.
Comment 4 Darin Wright CLA 2010-11-18 16:25:08 EST
Created attachment 183432 [details]
patch

The same editing/saving issue exists with breakpoint hit counts. This is a work in progress. It still needs some polish.
Comment 5 Darin Wright CLA 2010-11-19 12:39:10 EST
Created attachment 183488 [details]
patch

Applies a 200ms delay befores saving changes. Hit count is not working properly yet.
Comment 6 Eclipse Genie CLA 2020-07-26 16:50:44 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 7 Eclipse Genie CLA 2022-08-30 17:07:54 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.