Bug 104669 – [soup] http/tests/multipart/invalid-image-data.html fails even with soup multipart support

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Page Loading

[Jussi Kukkonen (jku)]

Bug 94515 was committed and soup multipart messages now work, yay.
invalid-image-data.html still fails to show a green rectangle, boo.

This happens on EFL and I believe on GTK as well.

[Chris Dumez]

Created attachment 191741 [details]
Patch

[WebKit Review Bot]

Attachment 191741 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/http/tests/multipart/invalid-image-data.html', u'LayoutTests/platform/efl/TestExpectations', u'LayoutTests/platform/efl/http/tests/multipart/invalid-image-data-expected.png', u'LayoutTests/platform/efl/http/tests/multipart/invalid-image-data-expected.txt', u'LayoutTests/platform/gtk/TestExpectations', u'LayoutTests/platform/gtk/http/tests/multipart/invalid-image-data-expected.png']" exit_code: 1
LayoutTests/platform/gtk/http/tests/multipart/invalid-image-data-expected.png:0:  Have to enable auto props in the subversion config file (/home/alancutter/.subversion/config "enable-auto-props = yes"). Have to set the svn:mime-type in the subversion config file (/home/alancutter/.subversion/config "*.png = svn:mime-type=image/png").  [image/png] [5]
Total errors found: 1 in 4 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Zan Dobersek]

Comment on attachment 191741 [details]
Patch

There's a large amount of stderr output on the GTK bots when running this test. Does the patch fix this?

http://build.webkit.org/results/GTK%20Linux%2064-bit%20Release/r144912%20(35298)/http/tests/multipart/invalid-image-data-stderr.txt

[Chris Dumez]

(In reply to comment #3)
> (From update of attachment 191741 [details])
> There's a large amount of stderr output on the GTK bots when running this test. Does the patch fix this?
> 
> http://build.webkit.org/results/GTK%20Linux%2064-bit%20Release/r144912%20(35298)/http/tests/multipart/invalid-image-data-stderr.txt

I was not aware of this stderr output. I did not notice it on EFL port so it is likely specific to GTK port.

[Chris Dumez]

I'll double check though

[Build Bot]

Comment on attachment 191741 [details]
Patch

Attachment 191741 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-commit-queue.appspot.com/results/17090002

New failing tests:
http/tests/multipart/invalid-image-data.html

[Build Bot]

Comment on attachment 191741 [details]
Patch

Attachment 191741 [details] did not pass mac-ews (mac):
Output: http://webkit-commit-queue.appspot.com/results/17042483

New failing tests:
http/tests/multipart/invalid-image-data.html
editing/selection/selection-modify-crash.html

[Chris Dumez]

(In reply to comment #3)
> (From update of attachment 191741 [details])
> There's a large amount of stderr output on the GTK bots when running this test. Does the patch fix this?
> 
> http://build.webkit.org/results/GTK%20Linux%2064-bit%20Release/r144912%20(35298)/http/tests/multipart/invalid-image-data-stderr.txt

I confirmed that the warnings are specific to GTK port and unrelated to multipart. I got you a backtrace here:
http://pastebin.com/f7DifDbR

The issue is actually in gtk's FrameLoaderClient::dispatchDidReceiveContentLength(). It appears the pointer returned by webkit_web_view_get_resource() is NULL and it is used later in a g_signal_emit_by_name() call.