Webkit Version 5.1 (7534.48.3, r95772) Thumbnails do not appear inside MobileMe gallery. Pictures load to a n epty or white frame , like the background. double click on the picture do display it works as expected. Work on in safari Version 5.1 (7534.48.3)
I can reproduce this in two ways. To reproduce as originally reported, you need to have a MobileMe account (a free trial should work): 1. Log in to me.com. 2. Go to one of your galleries (https://www.me.com/gallery/#galleryid) 3. Thumbnails are blank. Without loving in: 1. Open anyone's gallery (http://gallery.me.com/username#galleryid) 2. If thumbnails are visible, reload once or twice.
<rdar://problem/10176322>
Short version: The site is broken. We could do a site-specific hack to fix it. Long version: I don't have a me.com account, so I only debugged the reload case. I can debug the other case too, if desired. Here's what I see... The page seems to use some sort of preloading technique where it constructs an image element (I1) with the thumbnail's URL. The page then constructs 2 more image elements (I2 & I3) with the same URL. I3 is then used in HTMLCanvasElement::drawImage() and is what you normally see on the page. During the first page load: 1. I1 is new and loads. 2. I2 and I3 reuse the CachedImage loaded by I1, because it hasn't expired. 3. I3 is drawn successfully. During the reload: (all resources must revalidate because we're reloading) 1. I1 must revalidate and loads. 2. I2 must revalidate and loads. 3. I3 must revalidate. 4. drawImage(I3) is called, but I3 is still in the middle of revalidating. drawImage() fails. 5. I3 loads. According to the HTML5 and HTTP specs, WebKit's new behavior is correct and the page is broken. The page should wait for I3's load event to fire before drawing to the screen. Here's the steps I followed in the specs to come to that conclusion: 1. http://dev.w3.org/html5/spec/Overview.html#update-the-image-data step 6. 2. http://dev.w3.org/html5/spec/Overview.html#potentially-cors-enabled-fetch step 1. 3. http://dev.w3.org/html5/spec/Overview.html#fetch step 5. (Note: We're not already downloading, because I2 already completed.) 4. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html section 14.8, step 2. (Note: We MAY use the cache without revalidation, but don't because the user pressed reload.) 5. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-drawimage "If the image argument is an HTMLImageElement object that is not fully decodable ... then the implementation must return without drawing anything. 6. http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#img-good 7. http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#img-all We fail at #5, because the test in #7 fails, because #3 hasn't completed yet. Before bug 52153 was fixed, we never got to the revalidation step in CachedResourceLoader::determineRevalidationPolicy(). We used to always short-circuit out, because we'd already loaded the resource. The old behavior violates the HTTP spec regarding must-revalidate.
The logged-in case doesn't involve manual reloading, so perhaps the mechanism is somewhat different there.
I can't test that. It looks like they're no longer offering free trials. Is there a test account I can use instead? http://www.apple.com/mobileme/
*** Bug 72454 has been marked as a duplicate of this bug. ***
You can use this: http://gallery.me.com/smfr#100044&bgcolor=black&view=grid
Reporter, does this still happen for you? We can no longer reproduce.
Hi, I cannot reproduce either with latest nightly build Version 5.1.5 (7534.55.3, r114337) :) And wow it's fast !
Problem gone... with latest build... Thanks