RESOLVED FIXED 144546
Web Inspector: Exception under ContentViewContainer _disassociateFromContentView 
https://bugs.webkit.org/show_bug.cgi?id=144546
Summary Web Inspector: Exception under ContentViewContainer _disassociateFromContentView
Timothy Hatcher
Reported 2015-05-03 07:43:25 PDT
_disassociateFromContentView is being passed a BackForwardEntry instead of a ContentView in one case. There is also an associated logic error. I think this was masked by the fact that _disassociateFromContentView wouldn't call closed() if the representedObject was null on the passed object. Since BackForwardEntry doesn't have a representedObject, it would always abort early. This would lead to memory leaks too.
Attachments
Patch (2.20 KB, patch)
2015-05-03 07:46 PDT, Timothy Hatcher 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2015-05-03 07:43:41 PDT
<rdar://problem/20793755>
Timothy Hatcher
Comment 2 2015-05-03 07:46:00 PDT
Created attachment 252268 [details] Patch
Brian Burg
Comment 3 2015-05-03 15:10:13 PDT
Comment on attachment 252268 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=252268&action=review r=me > Source/WebInspectorUI/UserInterface/Views/ContentViewContainer.js:182 > + this._disassociateFromContentView(removedEntries[i].contentView); Would be prudent to add a type test for the method's parameter. (The method name is really clear, but this still slipped up.)
WebKit Commit Bot
Comment 4 2015-05-03 15:56:27 PDT
Comment on attachment 252268 [details] Patch Clearing flags on attachment: 252268 Committed r183733: <http://trac.webkit.org/changeset/183733>
WebKit Commit Bot
Comment 5 2015-05-03 15:56:31 PDT
All reviewed patches have been landed. Closing bug.
Timothy Hatcher
Comment 6 2015-05-03 18:07:47 PDT
Comment on attachment 252268 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=252268&action=review >> Source/WebInspectorUI/UserInterface/Views/ContentViewContainer.js:182 >> + this._disassociateFromContentView(removedEntries[i].contentView); > > Would be prudent to add a type test for the method's parameter. (The method name is really clear, but this still slipped up.) I think this happened during refactoring when you added BackForwardEntry into the mix instead of dealing with ContentViews directly. It was just masked by an early return that I recently removed. But yes, an assert for the type would normally be good.
Note You need to log in before you can comment on or make changes to this bug.