Closed Bug 915426 Opened 6 years ago Closed 5 years ago

Breakpoint set in one tab is triggered in another one

Categories

(DevTools :: Debugger, defect, P3)

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 35

People

(Reporter: till, Assigned: fitzgen)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

Jimb tells me that that's caused by all tabs sharing a single BreakpointStore.

Anyway, here's the STR:

1. visit http://www.areweflashyet.com/shumway/examples/inspector/inspector.html?rfile=../Box2DFlashAS3/demo.swf
2. open the debugger
3. set a breakpoint in embed.js:21
4. open a second tab
5. open the debugger in the second tab
6. visit the same url in the second tab

After this, execution will paus at embed.js:21.
Depends on: 895683
Priority: -- → P3
This seems completely opposite of what is requested in bug 883238. How should we resolve this?
(In reply to Nick Fitzgerald [:fitzgen] from comment #1)
> This seems completely opposite of what is requested in bug 883238. How
> should we resolve this?

Hum, excellent question. One possibility is to do what session restore does: give the option to restore previous state, but don't (or only optionally) do it by default.

However, what happens if you don't restore the state and then set different breakpoints in two open sessions?

And more generally, regardless of the decision here: how are updates in two open debugging sessions handled? Are they immediately reflected in the UI? I guess they have to be, but right now, they aren't, IINM.
(In reply to Till Schneidereit [:till] from comment #2)
> Hum, excellent question. One possibility is to do what session restore does:
> give the option to restore previous state, but don't (or only optionally) do
> it by default.

Not a huge fan of making the user think about this -- it should Just Work, IMO.

> However, what happens if you don't restore the state and then set different
> breakpoints in two open sessions?
> 
> And more generally, regardless of the decision here: how are updates in two
> open debugging sessions handled? Are they immediately reflected in the UI? I
> guess they have to be, but right now, they aren't, IINM.

Yeah, we should fix this and keep all sessions in sync, IMO.
Isn't the underlying issue here the same as bug 1010552?
Assignee: nobody → nfitzgerald
Status: NEW → ASSIGNED
Summary: Breakpoint set in one tab is triggered in another one with the same code → Breakpoint set in one tab is triggered in another one
Comment on attachment 8496838 [details] [diff] [review]
debugger-data-lifetimes.patch

LGTM
Attachment #8496838 - Flags: review?(ejpbruel) → review+
Uh oh: my new test failed on OSX.

260 INFO TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/debugger/test/browser_dbg_breakpoints-reload.js | Test timed out - expected PASS
Requesting longer timeout so that the new test can pass on linux debug.

https://tbpl.mozilla.org/?tree=Try&rev=d511377eb24d
Attachment #8496838 - Attachment is obsolete: true
Attachment #8498188 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/d9078f1bbcbe
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 35
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.