915426 - Breakpoint set in one tab is triggered in another one

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P3)

Description

[Till Schneidereit [:till]]

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.

Comment 1

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

This seems completely opposite of what is requested in bug 883238. How should we resolve this?

Comment 2

[Till Schneidereit [:till]]

(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.

Comment 3

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(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.

Comment 4

[Eddy Bruel [:ejpbruel]]

Isn't the underlying issue here the same as bug 1010552?

Comment 5

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Attachment: debugger-data-lifetimes.patch

https://tbpl.mozilla.org/?tree=Try&rev=595336519cc5

Comment 6

[Eddy Bruel [:ejpbruel]]

Comment on attachment 8496838 [details] [diff] [review]
debugger-data-lifetimes.patch

LGTM

Comment 7

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

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

Comment 8

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Attachment: debugger-data-lifetimes.patch

Requesting longer timeout so that the new test can pass on linux debug.

https://tbpl.mozilla.org/?tree=Try&rev=d511377eb24d

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/integration/fx-team/rev/d9078f1bbcbe

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/d9078f1bbcbe