resource:///org/webkit/inspector/UserInterface/Views/ContentView.js:193:132: CONSOLE ERROR Error: Can't make a ContentView for an unknown representedObject of type: CallFrame is printed to the console when navigating from a paused page.
Created attachment 384769 [details] Patch
Comment on attachment 384769 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=384769&action=review > Source/WebInspectorUI/UserInterface/Views/NavigationSidebarPanel.js:708 > - return true; > + return !!typeIdentifier; I don't really see a problem with this change on its own, but I want to know more about why/how this happens. I'd recommend adding a `console.trace()` in `WI.ContentView.createFromRepresentedObject` to see how this gets here. This solution may just mask an actual problem. Describing the steps to reproduce in the bug would also be appreciated :)
Comment on attachment 384769 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=384769&action=review >> Source/WebInspectorUI/UserInterface/Views/NavigationSidebarPanel.js:708 >> + return !!typeIdentifier; > > I don't really see a problem with this change on its own, but I want to know more about why/how this happens. I'd recommend adding a `console.trace()` in `WI.ContentView.createFromRepresentedObject` to see how this gets here. This solution may just mask an actual problem. > > Describing the steps to reproduce in the bug would also be appreciated :) Well, this change was made a month ago, I don't remember exact steps off the top of my head. I can try and reproduce it tomorrow maybe it manifested itself when fix for https://bugs.webkit.org/show_bug.cgi?id=204170 is applied.
Created attachment 384830 [details] test page ok, these are the steps to reproduce it on tip of tree: 1. Open inspector for the attached page 2. Click on 'Debugger' button 3. When execution breaks click on 'Navigate' button 4. Resume debugger Result: message in the console, frontend fails with the following trace Error: Can't make a ContentView for an unknown representedObject of type: CallFrame (at ContentView.js:193:132) createFromRepresentedObject @ ContentView.js:193:24 contentViewForRepresentedObject @ ContentView.js:214:72 showContentViewForRepresentedObject @ ContentBrowser.js:151:63 showDefaultContentViewForTreeElement @ NavigationSidebarPanel.js:202:82 _checkElementsForPendingViewStateCookie @ NavigationSidebarPanel.js:728:79 _checkOutlinesForPendingViewStateCookie @ NavigationSidebarPanel.js:684:53 finalAttemptToRestoreViewStateFromCookie @ NavigationSidebarPanel.js:257:57 finalAttemptToRestoreViewStateFromCookie @ [native code]
Comment on attachment 384769 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=384769&action=review >>> Source/WebInspectorUI/UserInterface/Views/NavigationSidebarPanel.js:708 >>> + return !!typeIdentifier; >> >> I don't really see a problem with this change on its own, but I want to know more about why/how this happens. I'd recommend adding a `console.trace()` in `WI.ContentView.createFromRepresentedObject` to see how this gets here. This solution may just mask an actual problem. >> >> Describing the steps to reproduce in the bug would also be appreciated :) > > Well, this change was made a month ago, I don't remember exact steps off the top of my head. I can try and reproduce it tomorrow maybe it manifested itself when fix for https://bugs.webkit.org/show_bug.cgi?id=204170 is applied. Added steps in #c4.
Devin, are you good with landing this?
(In reply to Yury Semikhatsky from comment #4) > Created attachment 384830 [details] > test page > > ok, these are the steps to reproduce it on tip of tree: > > 1. Open inspector for the attached page > 2. Click on 'Debugger' button > 3. When execution breaks click on 'Navigate' button > 4. Resume debugger > > Result: message in the console, frontend fails with the following trace > > Error: Can't make a ContentView for an unknown representedObject of type: > CallFrame (at ContentView.js:193:132) > createFromRepresentedObject @ ContentView.js:193:24 > contentViewForRepresentedObject @ ContentView.js:214:72 > showContentViewForRepresentedObject @ ContentBrowser.js:151:63 > showDefaultContentViewForTreeElement @ NavigationSidebarPanel.js:202:82 > _checkElementsForPendingViewStateCookie @ NavigationSidebarPanel.js:728:79 > _checkOutlinesForPendingViewStateCookie @ NavigationSidebarPanel.js:684:53 > finalAttemptToRestoreViewStateFromCookie @ NavigationSidebarPanel.js:257:57 > finalAttemptToRestoreViewStateFromCookie @ [native code] These steps don't reproduce for me. From what I can tell, it looks like the issue is that we're attempting to save/restore a `WI.CallFrame` as the currently selected `representedObject` likely in the `WI.SourcesNavigationSidebarPanel`. Whenever a navigation occurs, we're supposed to automatically resume, so I'm not really sure why/how this is happening. As far as this change, what if instead the check was added to the `if` right before? ``` if (!typeIdentifier || typeIdentifier !== representedObject.constructor.TypeIdentifier) ``` What happens with this patch applied? What is the difference in the UI? Does it end up calling through to `showDefaultContentView` because nothing matches the cookie, or does it do something else?
(In reply to Devin Rousso from comment #7) > (In reply to Yury Semikhatsky from comment #4) > > Created attachment 384830 [details] > > > > Error: Can't make a ContentView for an unknown representedObject of type: > > CallFrame (at ContentView.js:193:132) > > createFromRepresentedObject @ ContentView.js:193:24 > > contentViewForRepresentedObject @ ContentView.js:214:72 > > showContentViewForRepresentedObject @ ContentBrowser.js:151:63 > > showDefaultContentViewForTreeElement @ NavigationSidebarPanel.js:202:82 > > _checkElementsForPendingViewStateCookie @ NavigationSidebarPanel.js:728:79 > > _checkOutlinesForPendingViewStateCookie @ NavigationSidebarPanel.js:684:53 > > finalAttemptToRestoreViewStateFromCookie @ NavigationSidebarPanel.js:257:57 > > finalAttemptToRestoreViewStateFromCookie @ [native code] > These steps don't reproduce for me. > Are you trying to reproduce it on GTK Release build? Maybe there is some difference with other platforms as it's 100% reproducible in that configuration for me. > From what I can tell, it looks like the issue is that we're attempting to > save/restore a `WI.CallFrame` as the currently selected `representedObject` > likely in the `WI.SourcesNavigationSidebarPanel`. Whenever a navigation > occurs, we're supposed to automatically resume, so I'm not really sure > why/how this is happening. > The cookie is empty so I don't think we actually 'save' anything there. It's done as last resort as far as I can tell from this comment: // If the specific tree element wasn't found, we may need to wait for the resources // to be registered. We try one last time (match type only) after an arbitrary amount of timeout. this._finalAttemptToRestoreViewStateTimeout = setTimeout(finalAttemptToRestoreViewStateFromCookie.bind(this), relaxedMatchDelay); and the CallFrame just ends up being current represented object. > As far as this change, what if instead the check was added to the `if` right > before? > ``` > if (!typeIdentifier || typeIdentifier !== > representedObject.constructor.TypeIdentifier) > ``` > > What happens with this patch applied? What is the difference in the UI? > Does it end up calling through to `showDefaultContentView` because nothing > matches the cookie, or does it do something else? I don't see any obvious failures which I think is expected as !typeIdentifier should be equivalent to an empty cookie. If you feel confident about fixing it that way, I can do that. See the new patch.
Created attachment 385436 [details] Patch
Comment on attachment 385436 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=385436&action=review r=me, I'd still like to how how the GTK and Mac ports differ such that this can happen, but I don't really see any harm in this fix as is, so I think it's fine (with one change, and I apologize in advance) > Source/WebInspectorUI/UserInterface/Views/NavigationSidebarPanel.js:704 > + if (!typeIdentifier || typeIdentifier !== representedObject.constructor.TypeIdentifier) I feel bad for saying this, but I think what you had before was actually correct. We don't want to return if the cookie doesn't have a `WI.TypeIdentifierCookieKey` value, as many cookies don't have one. It's possible for the navigation sidebar to make it's own cookie that doesn't have anything to do with a `representedObject` type, and as such, this code as is would cause that to fail. I apologize for making you go back and forth. ``` if (matchTypeOnly) return !!typeIdentifier; ```
Comment on attachment 384769 [details] Patch Rejecting attachment 384769 [details] from commit-queue. Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-01', 'validate-changelog', '--check-oops', '--non-interactive', 384769, '--port=mac']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit ChangeLog entry in Source/WebInspectorUI/ChangeLog contains OOPS!. Full output: https://webkit-queues.webkit.org/results/13290561
Created attachment 385503 [details] Patch for landing
Comment on attachment 385503 [details] Patch for landing Clearing flags on attachment: 385503 Committed r253437: <https://trac.webkit.org/changeset/253437>
All reviewed patches have been landed. Closing bug.
<rdar://problem/57882907>