Setting Javascript breakpoint in pretty-printed JS file within IFrame causes browser hang




Developer Tools: Debugger
2 years ago
2 years ago


(Reporter: Simeon Morgan, Unassigned)


(Blocks: 1 bug, {hang})

39 Branch
Mac OS X

Firefox Tracking Flags

(Not tracked)




2 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.130 Safari/537.36

Steps to reproduce:

1. Open in Firefox
2. Right-click in IFrame and select Inspect Element
3. Choose the 'Debugger' tab in dev tools
4. Select 'firefox_issue_2.js' in Debugger
5. Press 'Stop blackboxing this source'
6. Press the pretty-print button
7. Set a breakpoint (must be somewhere that will actually be called, which is everywhere except the first function)
8. Refresh the broswer (which runs the code)
9. Wait for your browser to crash

This only appears to affect:
1. Minified code
2. Code that is executed when the page is loading: if you put a breakpoint in the function called by the button click (creatively called firedOnButtonClick) then click the button, it will not cause a crash. However, *it will not stop at the breakpoint either*

Actual results:

The browser crashed

Expected results:

Execution should have stopped at the breakpoint


2 years ago
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64

Comment 1

2 years ago
Also occurs on:
Win7, FF39
Win7, FF40
Win7, FF41

Doesn't occur if:
Breakpoint is set on the single minified line without pressing pretty-print (although it doesn't break at that breakpoint either...)
Seems to be specific to pretty-printed source code.

Comment 2

2 years ago
On my side, the browser doesn't crash but hangs so I need to kill it.
But I tested with Nightly and I'm not able to reproduce the hang.

Could you test with FF42, please.
Flags: needinfo?(github.wsot)

Comment 3

2 years ago
Sorry, you're right: the browser hangs rather than crashes.
I was able to reproduce it in Nightly, but only inconsistently (it didn't hang a much greater proportion of times than it did hang).
It may be unrelated, but every time I was able to reproduce it, the list of scripts on the left in the debugger only displayed the jquery script, not the firefox_issue_2.min.js.

The exact steps I followed:
1. Open the browser
2. Enter the URL
3. Right-click on the IFrame, select Inspect Element
4. When the dev tools load, select the 'Debugger' tab
5. Click 'Stop black boxing this source'
6. Click the pretty print icon
7. Click to the left of the 'var a;' line to add a breakpoint
8. Use the browser refresh button in the URL bar

If it didn't hang the first time I refreshed, it would never hang across many refreshes (I think).
If it didn't hang, I closed the browser window and dev tools, then selected 'File/New Tab', entered the URL, and tried again. Sometimes I would hang the second time. Rinse, repeat, enough cycles and it would always eventually hang. (Usually took 3-4 attempts)

That is Nightly on OSX.
Flags: needinfo?(github.wsot)

Comment 4

2 years ago
Yes, it hangs sometimes, maybe related to GC.

But it's less frequent in Nightly.
Component: Untriaged → Developer Tools: Debugger
Ever confirmed: true
Keywords: hang
Summary: Setting Javascript breakpoint in pretty-printed JS file within IFrame causes browser crash → Setting Javascript breakpoint in pretty-printed JS file within IFrame causes browser hang
Interesting, Instruments says we are spending 99% of our time in js::HashTable

> Running Time	Self (ms)		Symbol Name
> 25951.0ms   98.6%	0.0	 	js::detail::HashTable<js::AtomStateEntry const, js::HashSet<js::AtomStateEntry, js::AtomHasher, js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::readonlyThreadsafeLookup const  0x2d64a1
Blocks: 1070862
Which seems to be this use:

Wonder if that is just Instruments not seeing JS code, although I can't use our builtin profiler while Firefox is beachballed.

Comment 7

2 years ago
At the risk of introducing noise: could it be related to
In this issue, the browser hangs but I think it may only be the case if the outer window has no scripts. If the outer window has a script, that other issue occurs (i.e. the debugger stops in the outer window code) If the outer window doesn't have scripts the browser hangs.
(That was my experience anyway).
You need to log in before you can comment on or make changes to this bug.