Bug 204823 – Web Inspector: Error: Can't make a ContentView for an unknown representedObject of type: CallFrame

• Component: Web Inspector
• Status: RESOLVED FIXED

[Yury Semikhatsky]

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.

[Yury Semikhatsky]

Created attachment 384769 [details]
Patch

[Devin Rousso]

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 :)

[Yury Semikhatsky]

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.

[Yury Semikhatsky]

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]​

[Yury Semikhatsky]

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.

[Yury Semikhatsky]

Devin, are you good with landing this?

[Devin Rousso]

(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?

[Yury Semikhatsky]

(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.

[Yury Semikhatsky]

Created attachment 385436 [details]
Patch

[Devin Rousso]

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;
```

[WebKit Commit Bot]

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

[Yury Semikhatsky]

Created attachment 385503 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 385503 [details]
Patch for landing

Clearing flags on attachment: 385503

Committed r253437: <https://trac.webkit.org/changeset/253437>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/57882907>