Bug 83282 - Web Inspector: Allow inspection of Web Socket Frames
: Web Inspector: Allow inspection of Web Socket Frames
Status: RESOLVED FIXED
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated)
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To: Nobody
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-05 08:06 PDT by Konrad Piascik
Modified: 2012-04-27 07:24 PDT (History)
15 users (show)

See Also:


Attachments
Prototype (136.12 KB, image/png)
2012-04-05 08:07 PDT, Konrad Piascik
no flags Details
patch (16.07 KB, patch)
2012-04-05 08:12 PDT, Konrad Piascik
no flags Details | Formatted Diff | Diff
updated patch (16.08 KB, patch)
2012-04-05 08:33 PDT, Konrad Piascik
no flags Details | Formatted Diff | Diff
Screenshot. (29.59 KB, image/png)
2012-04-05 11:18 PDT, Konrad Piascik
no flags Details
Updated Screenshot (54.86 KB, image/png)
2012-04-13 14:01 PDT, Konrad Piascik
no flags Details
Patch (28.99 KB, patch)
2012-04-19 08:05 PDT, Konrad Piascik
no flags Details | Formatted Diff | Diff
Patch (32.64 KB, patch)
2012-04-19 10:29 PDT, Konrad Piascik
no flags Details | Formatted Diff | Diff
Patch (32.69 KB, patch)
2012-04-19 10:44 PDT, Konrad Piascik
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from ec2-cr-linux-04 (6.15 MB, application/zip)
2012-04-19 12:07 PDT, WebKit Review Bot
no flags Details
Patch (34.86 KB, patch)
2012-04-19 13:44 PDT, Konrad Piascik
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from ec2-cr-linux-02 (5.72 MB, application/zip)
2012-04-19 15:05 PDT, WebKit Review Bot
no flags Details
Patch (34.65 KB, patch)
2012-04-20 06:26 PDT, Konrad Piascik
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from ec2-cr-linux-01 (6.98 MB, application/zip)
2012-04-20 07:43 PDT, WebKit Review Bot
no flags Details
Patch (36.42 KB, patch)
2012-04-23 11:15 PDT, Konrad Piascik
no flags Details | Formatted Diff | Diff
Patch (36.53 KB, patch)
2012-04-23 12:09 PDT, Konrad Piascik
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from ec2-cr-linux-01 (6.30 MB, application/zip)
2012-04-24 02:38 PDT, WebKit Review Bot
no flags Details
Patch (35.68 KB, patch)
2012-04-24 06:15 PDT, Konrad Piascik
no flags Details | Formatted Diff | Diff
Patch (34.91 KB, patch)
2012-04-26 13:12 PDT, Konrad Piascik
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from ec2-cr-linux-03 (6.11 MB, application/zip)
2012-04-26 21:48 PDT, WebKit Review Bot
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Konrad Piascik 2012-04-05 08:06:33 PDT
Add Web Socket Frame inspection to the network item view.
Comment 1 Konrad Piascik 2012-04-05 08:07:11 PDT
Created attachment 135826 [details]
Prototype
Comment 2 Konrad Piascik 2012-04-05 08:12:45 PDT
Created attachment 135828 [details]
patch
Comment 3 WebKit Review Bot 2012-04-05 08:15:05 PDT
Attachment 135828 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/Modules/websockets/WebSocke..." exit_code: 1
Source/WebCore/Modules/websockets/WebSocketChannel.cpp:555:  Should have only a single space after a punctuation in a comment.  [whitespace/comments] [5]
Source/WebCore/inspector/InspectorResourceAgent.cpp:64:  Alphabetical sorting problem.  [build/include_order] [4]
Total errors found: 2 in 10 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 4 Konrad Piascik 2012-04-05 08:33:08 PDT
Created attachment 135832 [details]
updated patch
Comment 5 Pavel Feldman 2012-04-05 08:37:49 PDT
Comment on attachment 135828 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=135828&action=review

Your general approach looks good. Note that you need to provide change logs with your changes per WebKit policy.

> Source/WebCore/Modules/websockets/WebSocketChannel.cpp:556
> +    InspectorInstrumentation::didReceiveWebSocketFrame(m_document, m_identifier, frame);

I think you should report error frames as well.

> Source/WebCore/inspector/Inspector.json:685
> +                    { "name": "payloadLength", "type": "number", "description": "WebSocke frame payload length." },

Payload data length can be derived from the data in case you are sending the whole body. You should either sent truncated frames or skip this field.

> Source/WebCore/inspector/Inspector.json:891
> +                "name": "webSocketFrameResponseReceived",

webSocketFrameReceived? There are no requests / responses in WebSocket land. What about the webSocketFrameSent? You probably want to instrument frames going in both directions.

> Source/WebCore/inspector/Inspector.json:892
> +                "description": "Fired when WebSocket handshake response becomes available.",

Is this description accurate?

> Source/WebCore/inspector/Inspector.json:896
> +                    { "name": "response", "$ref": "WebSocketFrame", "description": "WebSocket response data." }

name: frame

> Source/WebCore/inspector/InspectorResourceAgent.cpp:460
> +    RefPtr<InspectorObject> responseObject = InspectorObject::create();

You should use the new type builder where possible:
RefPtr<TypeBuilder::Network::WebSocketFrame> frame = TypeBuilder::Network::WebSocketFrame::create()
    .setOpcode()
    .setMask()...

> Source/WebCore/inspector/front-end/NetworkItemView.js:62
> +        this.appendTab("frames", WebInspector.UIString("WebSocket Frames"), frameView);

appendTab("webSocketFrames", ...)

Please add new strings into English.lproj/localizedStrings.js in utf-16 encoding

> Source/WebCore/inspector/front-end/NetworkManager.js:454
> +            resource.payloads = {};

You should use array here:
resource.payloads = []. 
Also "payload" seems to be overloaded in the inspector world, so I would call it "frames" or "framePayloads"

> Source/WebCore/inspector/front-end/NetworkManager.js:455
> +            resource.payloads.size = 0;

size is always resource.frames.length

> Source/WebCore/inspector/front-end/NetworkManager.js:458
> +        resource.payloads[resource.payloads.size++] = response

resource.frames.push(response); This also is unbound growth, so you will drive the front-end out of memory eventually. Consider dropping frames.

> Source/WebCore/inspector/front-end/ResourceWebSocketFrameView.js:14
> + * You should have received a copy of the GNU Lesser General Public

You should provide BSD license with everything you contribute to the WebKit.

> Source/WebCore/inspector/front-end/ResourceWebSocketFrameView.js:33
> +        item.innerText = payload.time + '\t' + payload.opcode + ' ' + payload.mask + ' ' + payload.payloadLength + ' ' + payload.payloadData.substring(0, payload.payloadLength);

Please use String.sprintf defined in utilities.js

> Source/WebCore/inspector/front-end/ResourceWebSocketFrameView.js:66
> +            content += payload.opcode + ' ' + payload.mask ? 'true' : 'false' + ' ' + payload.payloadLength + ' ' + payload.payloadData + '\t' + payload.time + '<br>';

Please provide screenshots with the patches that contain UI changes.

> Source/WebCore/inspector/front-end/inspector.html:147
> +    <script type="text/javascript" src="ResourceWebSocketFrameView.js"></script>

You should also include this new file into the following projects / lists:
WebKit.qrc,
WebCore.gypi,
WebCore.vcproj,
compile-front-end.py
Comment 6 Pavel Feldman 2012-04-05 08:40:10 PDT
Comment on attachment 135832 [details]
updated patch

As per comments above.
Comment 7 Gustavo Noronha (kov) 2012-04-05 08:44:15 PDT
Comment on attachment 135828 [details]
patch

Attachment 135828 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/12341367
Comment 8 Build Bot 2012-04-05 08:47:26 PDT
Comment on attachment 135828 [details]
patch

Attachment 135828 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/12339341
Comment 9 WebKit Review Bot 2012-04-05 08:50:27 PDT
Comment on attachment 135828 [details]
patch

Attachment 135828 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12337326
Comment 10 Build Bot 2012-04-05 08:57:48 PDT
Comment on attachment 135828 [details]
patch

Attachment 135828 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/12264335
Comment 11 Gyuyoung Kim 2012-04-05 09:03:33 PDT
Comment on attachment 135828 [details]
patch

Attachment 135828 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/12340362
Comment 12 Konrad Piascik 2012-04-05 11:18:20 PDT
Created attachment 135864 [details]
Screenshot.

I'm open to suggestions as to how else this can be visualized.
Comment 13 Konrad Piascik 2012-04-05 13:53:21 PDT
is there a template for testing web inspector front-end changes?
Comment 14 Alexander Pavlov (apavlov) 2012-04-05 14:38:21 PDT
(In reply to comment #13)
> is there a template for testing web inspector front-end changes?

All web inspector tests reside in LayoutTests/inspector, LayoutTests/http/tests/inspector, and LayoutTests/http/tests/inspector-enabled. The latter two are for testing against a web server (which I guess is what you need), the former one is for the code that can deal with a local page. Find a test that is close to what you need and copy it! However, I'm not sure if our test web server supports web sockets...
Comment 15 Nikita Vasilyev 2012-04-12 13:48:10 PDT
Preview and Response tabs always show "This request has no preview available" and "This request has no response data available" respectively. Perhaps we can remove them.

> (In reply to comment #12)
> Created an attachment (id=135864) [details]
> Screenshot.
> 
> I'm open to suggestions as to how else this can be visualized.

How does it distinguish sent/received data?
Comment 16 Konrad Piascik 2012-04-12 13:55:27 PDT
(In reply to comment #15)
> Preview and Response tabs always show "This request has no preview available" and "This request has no response data available" respectively. Perhaps we can remove them.
> 
> > (In reply to comment #12)
> > Created an attachment (id=135864) [details] [details]
> > Screenshot.
> > 
> > I'm open to suggestions as to how else this can be visualized.
> 
> How does it distinguish sent/received data?

The above example, and code has only received data.  I've updated my patch locally to show sent data as well, but am still looking as to how to distinguish them.

I'll post another screenshot with an example soon...I'm also still working on tests.
Comment 17 Konrad Piascik 2012-04-13 14:01:57 PDT
Created attachment 137144 [details]
Updated Screenshot

Bi-directional text frames tracked.

Currently I don't distinguish between what is a sent vs received frame.  However the sent frames all seem to be masked while the received do not.
Will post updated patch with tests once I figure out how to write them.
Comment 18 Konrad Piascik 2012-04-19 08:05:27 PDT
Created attachment 137905 [details]
Patch
Comment 19 Konrad Piascik 2012-04-19 10:29:42 PDT
Created attachment 137919 [details]
Patch
Comment 20 Konrad Piascik 2012-04-19 10:44:28 PDT
Created attachment 137922 [details]
Patch

rebased patch so ews and style checker will apply/run correctly
Comment 21 Pavel Feldman 2012-04-19 10:51:22 PDT
Comment on attachment 137919 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=137919&action=review

Looks good overall. A bunch of style nits.

> Source/WebCore/ChangeLog:11
> +        * English.lproj/localizedStrings.js:

You should describe what has changed and why either via putting a paragraph of text above or inline methods summary below.

> Source/WebCore/Modules/websockets/WebSocketChannel.cpp:558
> +    InspectorInstrumentation::didReceiveWebSocketFrame(m_document, m_identifier, frame);

I wonder if you should move this below or into the call site: there is a number of guards and I am not sure you want inspector to have entries for the invalid data entries without declaring them invalid.

> Source/WebCore/Modules/websockets/WebSocketChannel.cpp:926
> +    InspectorInstrumentation::didSendWebSocketFrame(m_document, m_identifier, frame);

Same as above, you could fail below and inspector would show the frame as successfully sent.

> Source/WebCore/inspector/Inspector.json:901
> +                "name": "webSocketFrameErrorReceived",

webSocketFrameError ?

> Source/WebCore/inspector/InspectorInstrumentation.cpp:993
> +        if (InspectorResourceAgent* resourceAgent = instrumentingAgents->inspectorResourceAgent())

Here and below in the file: wrong indent.

> Source/WebCore/inspector/front-end/NetworkManager.js:468
> +        if (!networkRequest.frames)

You should not create fields on the object of another class. You should instead introduce NetworkRequest.prototype.addFrame() and frames() methods and annotate them for the compiler.

> Source/WebCore/inspector/front-end/NetworkManager.js:474
> +        if (networkRequest.frames.length >= 100)

You could encapsulate this into addFrame as well.

> Source/WebCore/inspector/front-end/NetworkManager.js:475
> +            networkRequest.frames.shift();

This looks inefficient. You should shift array in chunks, otherwise it'll be called for each frame.

> Source/WebCore/inspector/front-end/NetworkManager.js:524
> +        var errorFrame = {};

encapsulating it into NetworkRequest and creating a small class for the error frames there is the preferred way.

> Source/WebCore/inspector/front-end/ResourceWebSocketFrameView.js:25
> +    WebInspector.View.call(this);

This looks dense. Could you group the lines below via inserting blank lines?

> Source/WebCore/inspector/front-end/ResourceWebSocketFrameView.js:29
> +    var table = document.createElement('table');

Here and below: please use double quotations.

> Source/WebCore/inspector/front-end/ResourceWebSocketFrameView.js:33
> +    headerRow.appendChild(empty);

Note that DOMExtensions declares convenient Element.prototype.createChild for code like below.

> Source/WebCore/inspector/front-end/ResourceWebSocketFrameView.js:50
> +    for (var i = 0; i < this.resource.frames.length; i++) {

blank line above

> Source/WebCore/inspector/front-end/ResourceWebSocketFrameView.js:55
> +        count.innerText = (i + 1);

No need for ()

> Source/WebCore/inspector/front-end/ResourceWebSocketFrameView.js:61
> +        dateCell.innerHTML = String.sprintf("%s %s", (payload.sent ? "&rarr;" : (payload.errorMessage ? "" : "&larr;")), date.toISOString());

Assign to textContent, not innerHTML, otherwise, web socket would be able to inject javascript into the front-end page.
Comment 22 Pavel Feldman 2012-04-19 10:53:38 PDT
Comment on attachment 137922 [details]
Patch

Clearing r? to remove this from the dashboard. I reviewed the previous version of the patch already.
Comment 23 Build Bot 2012-04-19 11:08:27 PDT
Comment on attachment 137922 [details]
Patch

Attachment 137922 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/12437264
Comment 24 Konrad Piascik 2012-04-19 11:47:21 PDT
>> Source/WebCore/inspector/front-end/ResourceWebSocketFrameView.js:61
>> +        dateCell.innerHTML = String.sprintf("%s %s", (payload.sent ? "&rarr;" : (payload.errorMessage ? "" : "&larr;")), date.toISOString());
> 
> Assign to textContent, not innerHTML, otherwise, web socket would be able to inject javascript into the front-end page.

This isn't really a valid concern since the string being created is not comprised of user input of any kind.  I'm simply putting a left arrow (&larr;) or right arrow (&rarr;) to indicate whether it is a sent or received frame and then putting the date in an ISOString format.  The frame playload isn't being set as innerHTML.  It is set as innerText below.
Comment 25 WebKit Review Bot 2012-04-19 12:06:59 PDT
Comment on attachment 137922 [details]
Patch

Attachment 137922 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12345355

New failing tests:
http/tests/inspector/web-socket-frame.html
Comment 26 WebKit Review Bot 2012-04-19 12:07:07 PDT
Created attachment 137943 [details]
Archive of layout-test-results from ec2-cr-linux-04

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-04  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Comment 27 Konrad Piascik 2012-04-19 13:44:28 PDT
Created attachment 137969 [details]
Patch
Comment 28 Build Bot 2012-04-19 14:21:22 PDT
Comment on attachment 137969 [details]
Patch

Attachment 137969 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/12428717
Comment 29 WebKit Review Bot 2012-04-19 15:05:40 PDT
Comment on attachment 137969 [details]
Patch

Attachment 137969 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12297444

New failing tests:
http/tests/inspector/web-socket-frame.html
Comment 30 WebKit Review Bot 2012-04-19 15:05:47 PDT
Created attachment 137988 [details]
Archive of layout-test-results from ec2-cr-linux-02

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-02  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Comment 31 Pavel Feldman 2012-04-20 02:38:51 PDT
Comment on attachment 137969 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=137969&action=review

Few nits and it is good to go.

> Source/WebCore/inspector/front-end/NetworkRequest.js:810
> +    /**

You could narrow the API surface down via introducing single
frames() method.

> Source/WebCore/inspector/front-end/NetworkRequest.js:830
> +    getFrame: function(position)

WebKit guidelines discourages use of get prefixes. frame: function(position). I would strongly encourage you to simply expose frames: array here even if it returns live collection.

> Source/WebCore/inspector/front-end/NetworkRequest.js:863
> +            this._frames.splice(0,10);

Space before 10.

> Source/WebCore/inspector/front-end/ResourceWebSocketFrameView.js:67
> +        dateCell.innerHTML = String.sprintf("%s %s", (payload.sent ? "&rarr;" : (payload.errorMessage ? "" : "&larr;")), date.toISOString());

It does not really matter whether this is user data or not, you should only use innerHTML = for the (a) sanitized (b) HTML content. Otherwise it instantiates HTML parser, works slowly and results in vulnerabilities. You should look up \u symbol codes for the arrows and append them to your text content.

> Source/WebCore/inspector/front-end/ResourceWebSocketFrameView.js:73
> +            spanCell.innerText = payload.errorMessage;

innerText is not standard, uses weird semantics. You want .textContent = here.
Comment 32 Konrad Piascik 2012-04-20 06:26:52 PDT
Created attachment 138080 [details]
Patch
Comment 33 Build Bot 2012-04-20 06:58:06 PDT
Comment on attachment 138080 [details]
Patch

Attachment 138080 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/12476169
Comment 34 WebKit Review Bot 2012-04-20 07:43:24 PDT
Comment on attachment 138080 [details]
Patch

Attachment 138080 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12470236

New failing tests:
http/tests/inspector/web-socket-frame.html
Comment 35 WebKit Review Bot 2012-04-20 07:43:32 PDT
Created attachment 138094 [details]
Archive of layout-test-results from ec2-cr-linux-01

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-01  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Comment 36 Pavel Feldman 2012-04-20 08:36:53 PDT
Comment on attachment 138080 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=138080&action=review

One nit and I think it is ready.

> Source/WebCore/Modules/websockets/WebSocketChannel.cpp:932
> +    InspectorInstrumentation::didSendWebSocketFrame(m_document, m_identifier, frame);

The m_deflateFramer.deflate call above will mutate frame's data and, as a result, you will get garbled data instrumented. You could move this instrument call back to before deflate and assume that deflate is always successful. When we get a bug report claiming otherwise, we'll start instrumenting raw data*.
Comment 37 Konrad Piascik 2012-04-23 11:15:35 PDT
Created attachment 138389 [details]
Patch
Comment 38 Konrad Piascik 2012-04-23 11:54:07 PDT
Comment on attachment 138389 [details]
Patch

Needs to be rebased against ToT
Comment 39 Konrad Piascik 2012-04-23 12:09:24 PDT
Created attachment 138396 [details]
Patch
Comment 40 Build Bot 2012-04-23 13:34:23 PDT
Comment on attachment 138396 [details]
Patch

Attachment 138396 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/12490016
Comment 41 WebKit Review Bot 2012-04-24 02:38:35 PDT
Comment on attachment 138396 [details]
Patch

Attachment 138396 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12524231

New failing tests:
http/tests/inspector/web-socket-frame.html
Comment 42 WebKit Review Bot 2012-04-24 02:38:43 PDT
Created attachment 138527 [details]
Archive of layout-test-results from ec2-cr-linux-01

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-01  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Comment 43 Konrad Piascik 2012-04-24 06:15:32 PDT
Created attachment 138548 [details]
Patch
Comment 44 Build Bot 2012-04-24 06:43:39 PDT
Comment on attachment 138548 [details]
Patch

Attachment 138548 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/12522229
Comment 45 Jessie Berlin 2012-04-26 11:19:36 PDT
Comment on attachment 138548 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=138548&action=review

> Source/WebCore/inspector/InspectorAllInOne.cpp:26
> +// This all-in-one cpp file cuts down on template bloat to allow us to build our Windows release builds.

You shouldn't need to do this once you fix the actual causes of the build errors (see below).

> Source/WebCore/inspector/InspectorInstrumentation.h:74
> +class WebSocketFrame;

This is causing the build errors on Windows and I am not sure why it isn't causing build errors on other platforms.

WebSocketFrame is a struct, not a class, so the linker was trying to find a function that took a *class* WebSocketFrame when there was only one that took a *struct* WebSocketFrame.

Please forward declare it as a struct.

> Source/WebCore/inspector/InspectorResourceAgent.h:70
> +class WebSocketFrame;

This is causing the build errors on Windows. WebSocketFrame is a struct, not a class.
Comment 46 Jessie Berlin 2012-04-26 11:19:37 PDT
Comment on attachment 138548 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=138548&action=review

> Source/WebCore/inspector/InspectorAllInOne.cpp:26
> +// This all-in-one cpp file cuts down on template bloat to allow us to build our Windows release builds.

You shouldn't need to do this once you fix the actual causes of the build errors (see below).

> Source/WebCore/inspector/InspectorInstrumentation.h:74
> +class WebSocketFrame;

This is causing the build errors on Windows and I am not sure why it isn't causing build errors on other platforms.

WebSocketFrame is a struct, not a class, so the linker was trying to find a function that took a *class* WebSocketFrame when there was only one that took a *struct* WebSocketFrame.

Please forward declare it as a struct.

> Source/WebCore/inspector/InspectorResourceAgent.h:70
> +class WebSocketFrame;

This is causing the build errors on Windows. WebSocketFrame is a struct, not a class.
Comment 47 Konrad Piascik 2012-04-26 13:12:08 PDT
Created attachment 139053 [details]
Patch
Comment 48 WebKit Review Bot 2012-04-26 21:47:51 PDT
Comment on attachment 139053 [details]
Patch

Attachment 139053 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12551091

New failing tests:
fast/images/gif-large-checkerboard.html
Comment 49 WebKit Review Bot 2012-04-26 21:48:01 PDT
Created attachment 139130 [details]
Archive of layout-test-results from ec2-cr-linux-03

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-03  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Comment 50 WebKit Review Bot 2012-04-27 07:23:32 PDT
Comment on attachment 139053 [details]
Patch

Clearing flags on attachment: 139053

Committed r115427: <http://trac.webkit.org/changeset/115427>
Comment 51 WebKit Review Bot 2012-04-27 07:24:19 PDT
All reviewed patches have been landed.  Closing bug.