WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 200704
Web Inspector: Uncaught Exception: Content request failed.
https://bugs.webkit.org/show_bug.cgi?id=200704
Summary
Web Inspector: Uncaught Exception: Content request failed.
Devin Rousso
Reported
2019-08-14 01:22:38 PDT
Hit this on a ToT debug build when clicking websocket.js in the Resources tab. Content request failed. (at Resource.js:835:40) requestContentFromBackend @ Resource.js:835:40 requestContent @ SourceCode.js:140:100 _tryEnableCustomResponseContentView @ ResourceClusterContentView.js:367:38 ResourceClusterContentView @ ResourceClusterContentView.js:71:49 createFromRepresentedObject @ ContentView.js:52:53 contentViewForRepresentedObject @ ContentView.js:211:72 showContentViewForRepresentedObject @ ContentBrowser.js:151:63 showRepresentedObject @ ContentBrowserTabContentView.js:230:64 ? @ Main.js:1331:41 _treeSelectionDidChange @ ResourceSidebarPanel.js:487:37 dispatch @ Object.js:165:30 dispatchEventToListeners @ Object.js:172:17 _dispatchSelectionDidChangeEvent @ TreeOutline.js:1136:38 selectionControllerSelectionDidChange @ TreeOutline.js:813:46 _updateSelectedItems @ SelectionController.js:392:65 selectItem @ SelectionController.js:97:34 handleItemMouseDown @ SelectionController.js:258:28 _handleMouseDown @ TreeOutline.js:1122:54 _handleMouseDown @ [native code]
Attachments
Patch
(2.75 KB, patch)
2019-08-14 01:23 PDT
,
Devin Rousso
bburg
: review+
bburg
: commit-queue-
Details
Formatted Diff
Diff
Patch
(2.76 KB, patch)
2019-08-14 08:57 PDT
,
Devin Rousso
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Devin Rousso
Comment 1
2019-08-14 01:22:49 PDT
<
rdar://problem/54279372
>
Devin Rousso
Comment 2
2019-08-14 01:23:54 PDT
Created
attachment 376247
[details]
Patch
Greg Marriott
Comment 3
2019-08-14 01:35:09 PDT
Comment on
attachment 376247
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=376247&action=review
> Source/WebInspectorUI/UserInterface/Models/WebSocketResource.js:92 > + console.assert(false, "A WebSocket itself has no content, and should never be requested of as such.");
"A WebSocket's content was requested. WebSockets do not have content so the request is nonsensical."
Blaze Burg
Comment 4
2019-08-14 08:17:34 PDT
Comment on
attachment 376247
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=376247&action=review
r=me
>> Source/WebInspectorUI/UserInterface/Models/WebSocketResource.js:92 >> + console.assert(false, "A WebSocket itself has no content, and should never be requested of as such."); > > "A WebSocket's content was requested. WebSockets do not have content so the request is nonsensical."
+1 to Greg's wording :)
> Source/WebInspectorUI/UserInterface/Views/ResourceClusterContentView.js:369 > + return;
It would be nice to hook the websocket "response" view into the custom view machinery, but not necessary to fix this bug.
Devin Rousso
Comment 5
2019-08-14 08:56:05 PDT
Comment on
attachment 376247
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=376247&action=review
>> Source/WebInspectorUI/UserInterface/Views/ResourceClusterContentView.js:369 >> + return; > > It would be nice to hook the websocket "response" view into the custom view machinery, but not necessary to fix this bug.
It's already used by the "regular" response view above in `_contentViewForResourceType`. I see a difference between the "regular" response view and the "custom" response view. The "regular" view is something that's immediately deducible just from the resource type (e.g. an image should be displayed differently than text), whereas the "custom" view is for special situations where some aspect of the resource warrants additional UI (e.g. text is actually JSON content). We already do something like this for SVG images (I would argue that that's more of a special case though because I'd consider an SVG image to be _both_ textual and graphical, so even though showing both is "custom", I don't think it would fit here). In the case of WebSocket, I could see us creating (either here or making `WI.WebSocketContentView` into a cluster like SVG images) a JSON view where all frames are automatically shown as JSON views instead, but I'm not sure how common JSON is for frames (e.g. socket.io has it's own format).
Devin Rousso
Comment 6
2019-08-14 08:57:40 PDT
Created
attachment 376267
[details]
Patch
Joseph Pecoraro
Comment 7
2019-08-14 10:03:47 PDT
Comment on
attachment 376247
[details]
Patch Nice!
WebKit Commit Bot
Comment 8
2019-08-15 10:15:22 PDT
Comment on
attachment 376267
[details]
Patch Clearing flags on attachment: 376267 Committed
r248720
: <
https://trac.webkit.org/changeset/248720
>
WebKit Commit Bot
Comment 9
2019-08-15 10:15:23 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug