User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:15.0) Gecko/15.0 Firefox/15.0a1 Build ID: 20120511030513 Steps to reproduce: Closed the Markup panel in the Inspector, clicked away, clicked back again and tried to close. Actual results: There are 2 sets of "Rules/Computed" buttons, and there are 2 sets of breadcrumbs (each showing the same thing.) The 2nd set of breadcrumbs appears right by the side of the 1st. Same wiht the Rules/Computed buttons work. The Rules/Computed and breadcrumb buttons work but the exit button (X in lower right) doesn't. The Markup panel button doesn't work either (shows blank gray screen.) Expected results: I should have seen 1 set of each, the Markup panel should have shown the HTML, and the close button should have worked.

The screenshot looks funny :) So that's bad. I can't reproduce though. Can you reproduce with Firefox 14? Can you give some more detailed steps to reproduce? Do you have Firebug installed? And do you see any error message in the error console: Web Developer > Error Console (ctrl-shift-J)?

Confirming bug in Firefox 14.0.1. I was using the inspector, tried to close it and it exploded. I've attached a screenshot. Other details of interest are the Error Console which spat out: Error: TypeError: domRules is null Source File: resource:///modules/devtools/CssRuleView.jsm Line: 190 Timestamp: 6/08/2012 3:44:35 PM Error: TypeError: aContext is null Source File: resource:///modules/devtools/StyleInspector.jsm Line: 80 Timestamp: 6/08/2012 3:44:41 PM Error: TypeError: domRules is null Source File: resource:///modules/devtools/CssRuleView.jsm Line: 190 Reproduction is hard. This has happened to me twice (this being the second time), it's random. [This Firefox instance has been open for a week and is pushing above 1GiB RAM usage so the cycle collector and garbage collector are stuck in overdrive (3-6% constant CPU usage), this might be causing random thread delays that then end up posting events in the wrong order or something]

Still present in 15.0. I think I missed the initial Error Console logs but it did fill up with these: Timestamp: 01/09/2012 9:42:36 AM Error: TypeError: can't access dead object Source File: resource:///modules/highlighter.jsm Line: 333 Timestamp: 01/09/2012 9:42:36 AM Error: TypeError: can't access dead object Source File: resource:///modules/highlighter.jsm Line: 333 Timestamp: 01/09/2012 9:42:36 AM Error: TypeError: can't access dead object Source File: resource:///modules/devtools/LayoutView.jsm Line: 294 Timestamp: 01/09/2012 9:42:36 AM Error: TypeError: can't access dead object Source File: resource:///modules/devtools/LayoutView.jsm Line: 294 Those 4 errors just repeat as a group over and over.

Okay, I've found a way to consistently cause the inspector to crash every time. All you have to do is try to inspect an element inside an IFRAME, then have a JavaScript delete the IFRAME whilst the inspector is still selected on an element inside of it. The selected element highlight box will stick in place and the inspector will crash. You can do this multiple times (refresh the page and do the steps again and again) to stack multiple crashed panels on top of each other. This affects real websites that use IFRAMEs as previews or Rich Text Editors, changing modes causes the IFRAME to be destroyed and it will kill the inspector if you were using it inside the frame when that happens.

We might want to use tests from bug 818001.

I just tried this with the latest fx-team code level and here is what's happening for me: - the highlighter dashed line stays where the inspected element was - the breadcrumbs stay as they were when the element was inspected - the style inspector keep on showing the element's styles - the markup-view however, refreshes itself to show the new state of the DOM. So that's a problem in itself, but not as serious as described in comment 4 I believe. In my case, as soon as you select another element or click on the breadcrumb or switch to the computed view, then the inspector goes back to "normal", with no node selected anymore. So, if I haven't missed anything here, what we should really fix is refresh the breadcrumb, highlighter and style inspector/computed view when the current selection disappears. Probably using the mutation observer.