Bug 37796 - JPG images fail to print in Chromium
Summary: JPG images fail to print in Chromium
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh Intel OS X 10.6
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-19 06:49 PDT by Avi Drissman
Modified: 2010-04-21 14:33 PDT (History)
4 users (show)

See Also:


Attachments
Patch to avoid bug. (2.04 KB, patch)
2010-04-19 06:52 PDT, Avi Drissman
no flags Details | Formatted Diff | Diff
Yes, Miss Style Bot. (2.09 KB, patch)
2010-04-19 07:08 PDT, Avi Drissman
simon.fraser: review+
simon.fraser: commit-queue-
Details | Formatted Diff | Diff
Better ChangeLog description, no code change. (2.29 KB, patch)
2010-04-20 10:07 PDT, Avi Drissman
avi: review-
avi: commit-queue-
Details | Formatted Diff | Diff
A little more precision. Still no code change. (2.30 KB, patch)
2010-04-20 10:08 PDT, Avi Drissman
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Avi Drissman 2010-04-19 06:49:40 PDT
Upstream from http://code.google.com/p/chromium/issues/detail?id=33239 .

<rdar://problem/7874035> (<http://openradar.appspot.com/7874035>): Any image source with final=false will fail to draw into a PDF context even when later updated with final=true. Therefore when the final data comes in for an image, we need to destroy and re-create the image source.
Comment 1 Avi Drissman 2010-04-19 06:52:05 PDT
Created attachment 53675 [details]
Patch to avoid bug.
Comment 2 WebKit Review Bot 2010-04-19 06:56:32 PDT
Attachment 53675 [details] did not pass style-queue:

Failed to run "WebKitTools/Scripts/check-webkit-style" exit_code: 1
WebCore/platform/graphics/cg/ImageSourceCG.cpp:131:  Use 0 instead of NULL.  [readability/null] [5]
WebCore/platform/graphics/cg/ImageSourceCG.cpp:136:  Use 0 instead of NULL.  [readability/null] [5]
Total errors found: 2 in 2 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 3 Avi Drissman 2010-04-19 07:08:46 PDT
Created attachment 53676 [details]
Yes, Miss Style Bot.
Comment 4 Simon Fraser (smfr) 2010-04-20 09:59:19 PDT
Comment on attachment 53676 [details]
Yes, Miss Style Bot.

> Index: WebCore/ChangeLog
> ===================================================================
> --- WebCore/ChangeLog	(revision 57809)
> +++ WebCore/ChangeLog	(working copy)
> @@ -1,3 +1,13 @@
> +2010-04-19  Avi Drissman  <avi@chromium.org>
> +
> +        Reviewed by NOBODY (OOPS!).
> +
> +        JPG images fail to print in Chromium
> +        https://bugs.webkit.org/show_bug.cgi?id=37796

This needs more verbage to say what the underlying problem is (referencing the radar), and what you did to fix it.

r=me
Comment 5 Avi Drissman 2010-04-20 10:07:39 PDT
Created attachment 53833 [details]
Better ChangeLog description, no code change.
Comment 6 Avi Drissman 2010-04-20 10:08:54 PDT
Created attachment 53834 [details]
A little more precision. Still no code change.
Comment 7 WebKit Commit Bot 2010-04-21 05:23:06 PDT
Comment on attachment 53834 [details]
A little more precision. Still no code change.

Clearing flags on attachment: 53834

Committed r57969: <http://trac.webkit.org/changeset/57969>
Comment 8 WebKit Commit Bot 2010-04-21 05:23:11 PDT
All reviewed patches have been landed.  Closing bug.
Comment 9 James Robinson 2010-04-21 12:57:24 PDT
I think this broke http/tests/multipart/invalid-image-data.html, see http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpectations=true&tests=http%2Ftests%2Fmultipart%2Finvalid-image-data.html&useWebKitCanary=true

Is this a regression or a progression?
Comment 10 Avi Drissman 2010-04-21 13:44:23 PDT
I actually don't know.

Lin/Win were displaying blank because they were incorrectly showing the second image which wasn't decoding correctly (see http://code.google.com/p/chromium/issues/detail?id=8729). The Mac was working correctly?

Looking at the code that put the test in, it's dealing with saving/extracting the data at a level totally different than the one I'm dealing with...
Comment 11 Avi Drissman 2010-04-21 14:31:35 PDT
So apparently Chromium Mac is now broken in the same way as Chromium Win/Lin is, rather than unexpectedly passing. I don't know if that's a good or bad thing.
Comment 12 James Robinson 2010-04-21 14:33:44 PDT
Hmm.  I've marked it as an expected failure for now and will file a separate bug to track it (if we don't have one already).