Closed Bug 962724 Opened 6 years ago Closed 6 years ago
Event listeners don't persist after attach and reopening of Developer Tools
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release) Build ID: 20140122030521 Steps to reproduce: 1) Go to a webpage with event listeners (e.g. http://todomvc.com/architecture-examples/angularjs/) 2) Open Developer Tools » Debugger » Expand Panes » Events 3) Click to toggle on an event (e.g. "click") 4) Close the Developer Tools and reopen them as in 2). Actual results: The debugger breaks and the "Events" pane shows "No event listeners to display". Expected results: The debugger shouldn't break/stop and the "Events"-pane should show the event listeners.
Assignee: nobody → past
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2
The problem was that a native event listener in this page did provide a listenerObject, but not a type, which wasn't something we thought possible. I'm not adding a unit test for this tiny fix, because I don't know how to create a native event listener with this particular behavior.
Attachment #8366532 - Flags: review?(vporof)
Comment on attachment 8366532 [details] [diff] [review] Ignore native event listeners without a type Review of attachment 8366532 [details] [diff] [review]: ----------------------------------------------------------------- Sure.
Attachment #8366532 - Flags: review?(vporof) → review+
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
Comment on attachment 8366532 [details] [diff] [review] Ignore native event listeners without a type [Approval Request Comment] Bug caused by (feature/regressing bug #): not sure if this is a recent change or has been present ever since the event listeners appeared on the debugger UI in Firefox 27 User impact if declined: closing and reopening the devtools in a page would display an empty events list Testing completed (on m-c, etc.): m-c Risk to taking this patch (and alternatives if risky): minimal risk, trivial patch, devtools-only String or IDL/UUID changes made by this patch: none
Attachment #8366532 - Flags: approval-mozilla-aurora?
Tested on beta and it works as expected, so this is caused by something else in the Firefox 28 timeframe.
Attachment #8366532 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Sounds good for Aurora!
Verified as fixed on Firefox 28 beta 1 (20140205162153) and Aurora 29.0a2 (20140206004003) under Mac OSX 10.8.5 and Win 7 64-bit.
You need to log in before you can comment on or make changes to this bug.