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.
Created attachment 53675 [details] Patch to avoid bug.
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.
Created attachment 53676 [details] Yes, Miss Style Bot.
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
Created attachment 53833 [details] Better ChangeLog description, no code change.
Created attachment 53834 [details] A little more precision. Still no code change.
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>
All reviewed patches have been landed. Closing bug.
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?
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...
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.
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).