Bug 68682 - REGRESSION (r93326): Thumbnails do not appear inside MobileMe gallery
Summary: REGRESSION (r93326): Thumbnails do not appear inside MobileMe gallery
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: Images (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh OS X 10.7
: P1 Major
Assignee: Nobody
URL: https://www.me.com/gallery/#galleryid
Keywords: InRadar, Regression
: 72454 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-09-23 02:08 PDT by requin.l
Modified: 2012-04-17 08:47 PDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description requin.l 2011-09-23 02:08:06 PDT
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)
Comment 1 Alexey Proskuryakov 2011-09-23 11:20:35 PDT
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.
Comment 2 Alexey Proskuryakov 2011-09-23 11:21:28 PDT
<rdar://problem/10176322>
Comment 3 James Simonsen 2011-09-29 21:50:40 PDT
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.
Comment 4 Alexey Proskuryakov 2011-09-29 22:07:43 PDT
The logged-in case doesn't involve manual reloading, so perhaps the mechanism is somewhat different there.
Comment 5 James Simonsen 2011-09-30 11:43:54 PDT
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/
Comment 6 Alexey Proskuryakov 2011-11-16 14:35:19 PST
*** Bug 72454 has been marked as a duplicate of this bug. ***
Comment 7 Simon Fraser (smfr) 2011-12-06 13:33:11 PST
You can use this:
http://gallery.me.com/smfr#100044&bgcolor=black&view=grid
Comment 8 Alexey Proskuryakov 2012-04-16 12:24:49 PDT
Reporter, does this still happen for you? We can no longer reproduce.
Comment 9 requin.l 2012-04-17 03:22:52 PDT
Hi, I cannot reproduce either with latest nightly build Version 5.1.5 (7534.55.3, r114337) :)
And wow it's fast !
Comment 10 Jim Oase 2012-04-17 07:31:30 PDT
Problem gone... with latest build...  Thanks