STR: 1. Go to http://htmlpad.org/debugger/ 2. Open Debugger 3. Toggle the instruments side pane visible (on the right) 4. Click the Events tab Console spew: "scheduleEventListenersFetch threw an exception: Error getting function definition site: conn5.pausedobj58 has no Debugger.Script" The debugger remains paused and the debuggee page can't be interacted with.

(latest Nightly, 25-Nov-2013)

Opening the Events tab on this page (this bug) crashes Nightly: https://crash-stats.mozilla.com/report/index/752a01d0-ca42-41aa-8e6c-9bbc92131125

Panos, a hint about who we should ping about this? :(

Wait, the crash is a dupe, but the error messages didn't appear in the other bug, so let's fix those here. I expect they are a regression from bug 917583.

I can't repro on the latest Nightly and OSX 10.8 :-/

(In reply to Nick Fitzgerald [:fitzgen] from comment #6) > I can't repro on the latest Nightly and OSX 10.8 :-/ I think this might be 10.9 only.

I can no longer reproduce this on 10.8. Will update over the weekend and retest on 10.9.

browser_dbg_break-on-dom-05.js fails on my machine (OS X 10.9), however it's all green on try (because there are no runs for 10.9).

That test works for me on 10.9. What was the crash log like? Could it be retina-related? I should also note that I'm using the default (10.9) SDK in my local build (the one which results in a smaller browser font). Are you using something else? Furthermore I can no longer reproduce the exceptions from comment 0, so I'm inclined to mark this bug as a duplicate of 936604 again.

This is my mozconfig: https://gist.github.com/victorporof/4078653 I'm building with the 10.8 SDK. If I disable retina, the test still fails. The crash log is in comment 2. However, I never managed to get any crashes out of this anymore.

I was actually referring to the crash log from the mochitest, but looking at your mozconfig I don't think you are set up for getting one. Here are the necessary steps: https://developer.mozilla.org/en-US/docs/Mochitest#stacks I'll try building with the 10.8 SDK to see if this results in a reproducible crash, but if the stack is the same we should just dupe this. Do you see the error messages from comment 0 any more?

The test was re-enabled and I can non longer see the error messages, so I'm marking as duplicate again.

I'm still getting the error in latest nightly with an empty profile on OS X 10.9. scheduleEventListenersFetch threw an exception: Error getting function definition site: conn3.pausedobj56 has no Debugger.Script

Tried with an empty profile on 10.9 with both nightly and a debug build of fx-team tip. I still can't reproduce it. I only had a single tab open to htmlpad.org/debugger and no error messages appeared anywhere. If you can reproduce it reliably, it would be useful to post the grip or some more information about the function object that produces this error.

OK, I can reproduce this again on http://todomvc.com/vanilla-examples/vanillajs/. Looking into it.

I don't have time right now to see what happens inside the engine causing those event listeners to not have Debugger.Script references, but at the very least the frontend shouldn't abort when it encounters one of them. This is just a patch to keep things reasonably functional, further investigation is still required.

Comment on attachment 8371341 [details] [diff] [review] Keep populating the Events pane even in the presence of event listeners with no associated Debugger.Script Review of attachment 8371341 [details] [diff] [review]: ----------------------------------------------------------------- This was very much needed! Thank you! Is there any way to simulate this behavior? If so, it'd be great if you could write a test for this to make sure the debuggee remains usable and can be interacted with.

I haven't figured out why some event listeners are returned like that, so I don't know how to write a test. That will definitely be part of the followup work though.

Putting this back in the pool for now.

The current state of this bug is that the events pane should always display a list of listeners, but in some corner cases the listener might indicate [native code] as its source. The problem seems to be that we can't properly unwrap the security wrappers of the listener, as Debugger.Object.prototype.unwrap() returns null. cnn.com has been a reliable source of such events so far.

This regressed in [1] when bug 905700 landed. See bug 1145996. [1] https://hg.mozilla.org/mozilla-central/rev/ce5a390e46a9

Here's a patch that restores the previous behavior so that a missing Debugger.Source object does not stop the pane from populating. The only difference with the previous fix is that the unknown handler is hidden from the UI as breaking on it does not seem to work. This can be trivially reverted if you think they should be shown in the list anyway. This time it has a test though I had to disable it on e10s and debug builds due to addon-sdk bug 1142597 (debug) and bug 1146603 (e10s). Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5780dfbc67fe

Rebased on top of latest fx-team tip.

Not sure I totally follow this bug's evolution... Panos, you added the leave-open, is there anything left to do now?

The problem is what I summed up in comment 23: in some cases (e.g. cnn.com) there is no associated source with an event listener, so we can't break on it. However the fix that landed in comment 29 no longer lets these event listeners appear in the UI, so you have to look at the console to see the errors. I had hoped that by showing these listeners in the UI we would be compelled to fix this sooner, but clearly that was not the case. Someone needs to sit down and figure out why the debugger server doesn't have access to the Debugger.Script of those listeners.