|Summary:||Clear failed image loads when an <img> is adopted into a different document|
|Product:||WebKit||Reporter:||Adam Klein <adamk>|
|Component:||New Bugs||Assignee:||Adam Klein <adamk>|
|Severity:||Normal||CC:||ap, beidson, darin, japhet, rniwa, webkit.review.bot|
|Version:||528+ (Nightly build)|
Description Adam Klein 2012-12-07 16:00:58 PST
Remove bogus assert from ImageLoader
Comment 2 Adam Klein 2012-12-07 16:07:45 PST
From reading the ways m_failedLoadURL is used, it seems like it's safe to just remove this assert, but I'm not at all an ImageLoader expert so I'm looking for help from the reviewer to decide if I need to do something other than remove the assert.
Comment 3 Darin Adler 2012-12-08 11:05:56 PST
Comment on attachment 178298 [details] Patch I think that the gist of this assertion is to say that the function doesn’t do what anything appropriate with the failed load URL, which the original programmer thought was OK because that can never happen. Removing the assertion is clearly OK, but I think that additional work, such as clearing m_failedLoadURL, may be needed.
Comment 4 Adam Klein 2012-12-10 10:21:50 PST
Clearing m_failedLoadURL seems reasonable in this case, and at worst will just cause a re-fetch, it looks like. Shall I just do that?
Comment 6 Adam Klein 2012-12-18 11:30:22 PST
Darin, can you take another look at this?
Comment 7 WebKit Review Bot 2013-01-03 11:53:45 PST
Comment on attachment 179514 [details] Patch Clearing flags on attachment: 179514 Committed r138724: <http://trac.webkit.org/changeset/138724>
Comment 8 WebKit Review Bot 2013-01-03 11:53:48 PST
All reviewed patches have been landed. Closing bug.
Comment 9 Ryosuke Niwa 2013-01-03 14:42:12 PST
It appears that this patch broke WebKit1.MemoryCachePruneWithinResourceLoadDelegate: Pass: http://build.webkit.org/builders/Apple%20MountainLion%20Debug%20WK2%20%28Tests%29/builds/5409 Fail: http://build.webkit.org/builders/Apple%20MountainLion%20Debug%20WK2%20%28Tests%29/builds/5410 Blame range: http://trac.webkit.org/log/?verbose=on&rev=138726&stop_rev=138721 On the other hand, http://build.webkit.org/builders/Apple%20MountainLion%20Debug%20WK1%20%28Tests%29?numbuilds=25 says it’s r138726, which is quite inconceivable.