24711 2014-02-18 12:36:21 +0000 <img>: Refactor the image loading model 2014-06-16 18:41:44 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#update-the-image-data P2 normal Unsorted 1 contributor zcorpan annevk bzbarsky ian johns mike zcorpan contributor oldest_to_newest 100798 0 contributor 2014-02-18 12:36:21 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html Multipage: http://www.whatwg.org/C#update-the-image-data Complete: http://www.whatwg.org/c#update-the-image-data Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/ Comment: Should probably only abort the fetch if the selected source is different from the last selected source. (step 2) Posted from: 90.230.218.37 by simonp@opera.com User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_8) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.90 Safari/537.1 101287 1 ian 2014-02-24 23:13:39 +0000 This test says Safari/Chrome do what the spec says: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2840 ...whereas Firefox does what you suggest. 101288 2 ian 2014-02-24 23:22:31 +0000 Nevermind, that test is busted. This shows that Safari/Chrome do what you suggest, but Firefox does what the spec says: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2845 101426 3 zcorpan 2014-02-26 07:17:40 +0000 OK, good that there is impl precedent. :-) 101437 4 ian 2014-02-26 15:39:37 +0000 Any Firefox people want to make a case for leaving the spec as is rather than changing to the arguably better behaviour of not aborting the load in the redundant case? (Note that this doesn't affect srcset changes based on environment changes, since those loads use a different algorithm.) 101438 5 bzbarsky 2014-02-26 15:53:23 +0000 > This shows that Safari/Chrome do what you suggest, but Firefox does what the > spec says: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2845 How does this testcase show anything about the behavior? The main hard web compat constraint here I'm aware of is that given a loaded image, setting its src to the same value should check whether it's expired (HTTP caching semantics) and if so reload the image. Gecko implements this by just always forcing a load on src set; if there is an existing load (whether done or not), it's dropped to make way for the new one. 101565 6 ian 2014-02-28 00:16:13 +0000 slow-second-dim.cgi is a script that takes 3 seconds and returns an image whose width equals the current time's seconds component. I should probably have mentioned that. :-) This bug is just about whether to drop the existing load and trigger a new one, or defer to an already-in-flight load if there is one. I don't think it affects the compat need mentioned in comment 5, since either way we are doing a load. 101598 7 bzbarsky 2014-02-28 05:04:33 +0000 So what matters for the testcase is whether the two logged widths are identical? > or defer to an already-in-flight load if there is one. This involves some fun defining of what makes for an in-flight load. If the load has the image metadata but but not all the image data, is it in-flight? If it's an animated gif and it has the first frame but not the other frames yet, is it in-flight? If the bits are off the wire and in the image library but the DOM doesn't know anything about that yet, is the image in-flight? I'm probably OK trying to change Gecko's behavior here assuming there's a clear spec and a good reason to make the change, but it would be pretty low priority, I suspect. 101664 8 ian 2014-02-28 22:00:01 +0000 bz: Well from a spec perspective I would just define it as an ongoing instance of the "fetch" algorithm. In practice the edge cases are a race condition that I don't think your could black-box text anyway, so it probably doesn't need to be super-precise. zcorpan: Your call. Do you still want to make this change given bz's comments? The spec's current state (what Firefox does) has fewer potential races... 101672 9 bzbarsky 2014-02-28 22:05:46 +0000 You can black-box test things like "size available, data is not" to some extent, if you control the server... Especially given animated gifs. We've run into problems with that sort of timing issue for images in the past. :( 101680 10 ian 2014-02-28 23:49:23 +0000 Those would both fall under "an ongoing instance of the "fetch" algorithm". 101690 11 bzbarsky 2014-03-01 03:06:24 +0000 Yes, but is that compatible? As in, if you do img.src = img.src on an image in that state, you're saying it should be a no-op. Is that what UAs currently do in that situation and what sites expect? 101779 12 ian 2014-03-03 19:44:36 +0000 I dunno about what sites expect. From what I can tell, it's not what Gecko does, it is what Safari/Chrome do; see the test in comment 2. 101783 13 bzbarsky 2014-03-03 20:21:05 +0000 The test in comment 2 is not testing a partially-downloaded animated gif. 101784 14 bzbarsky 2014-03-03 20:23:03 +0000 To make my concern clearer: I'm willing to consider switching to another widely-implemented behavior. I'm less willing to consider switching to a simplified version of another widely-implemented behavior; we've been bitten far too often recently by doing that and discovering that the differences in various edge cases meant the simplified version is not web-compatible. A clear description from some WebKit/Blink folks about what their exact behavior is would be a good start in evaluating how happy I am with it... 101876 15 ian 2014-03-04 23:56:58 +0000 Can you elaborate on your animated GIF concern? I guess I didn't understand what you meant by "that state" in comment 11. 101889 16 bzbarsky 2014-03-05 02:40:22 +0000 Say I have an animated gif. The UA has some frames and has started showing them, but the rest of the data is coming in from the network so the fetch is still in progress. Now the page does img.src = img.src on that gif. What should happen? Is a new network load started? Does the animation get reset to the beginning? 101938 17 ian 2014-03-05 23:14:24 +0000 Crazy. With animated GIFs, I get the opposite result. http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2869 I'm very confused now. 101960 18 bzbarsky 2014-03-06 03:27:13 +0000 Is that test testing network requests, or just whether the animation is restarted? 102012 19 ian 2014-03-06 19:35:44 +0000 Both, though detecting a new request is a bit subtle (as far as I can tell, if it's a new request, you'll get a bigger pause between "0" and "2" than if the UA already has the data). In the results below, a comma indicates a one-second-or-so pause, Z indicates that the log just had "zapped" added to it. Chrome and Safari restart the animation, but don't start a new load. That is, they render: (blank space),,0,,12,3,4,5Z,0,1,2,3,4,5,6,7,8,9,A,b,C,d,E,F.,0,1,2.... Firefox doesn't restart the animation until the load is over, and then it does. It doesn't actually trigger a new network request (according to the Web console, anyway. Not sure how reliably that is. But it matches the results — if there was a new request here, you'd expect a stutter between the second "0" and "2"). That is, it renders: (placeholder),,0,,2,3,4,5Z,6,7,8,9,A0,1,2,3,4,5,6,7,8,9,A,b,C,d,E,F.,0,1,2... I guess the difference between this test and the earlier one is that here we have already started decoding by the time the URL changes? If that's what Firefox is relying on, it seems like a very race-prone design (more so even than just relying on the network connection being open — at least the author has some visibility into that on the client and server side via events, even if it's not precise). 102014 20 bzbarsky 2014-03-06 19:55:39 +0000 Oh, I see part of the confusion here. So what Gecko does is it can have up to two "image requests" per image element: a "current" one and a "pending" one. An "image request" includes both the fetch and the resulting data. When we go to do the equivalent of "update the image data", we check whether the current request is in a state where we know the size of the image. If it is, we make the new request a "pending request" and keep showing the old thing until the new request's size is available. Then we drop the old "current request" and make the pending request be current. The intent of the setup is that if you have an <img> whose src you set to different things every so often (like a slideshow, say), but the loads are slow you don't keep bouncing between "showing an image" and "broken image, with different layout". That's why the size-available check is important: that's when your layout is likely to stay stable. I just tested Chrome, using a testcase like so: <!DOCTYPE html> <img height='10' src="http://software.hixie.ch/utilities/cgi/dynamic-images/second-dim.cgi"> <script> onload = function() { document.querySelector("img").src = "http://software.hixie.ch/utilities/cgi/dynamic-images/slow-second-dim.cgi"; } </script> and they also seem to keep the current image showing while the new one loads, as far as I can tell. I don't know how they decide when to do that or not. 102561 21 zcorpan 2014-03-18 14:25:40 +0000 Comment 5 seems like a new spec bug. img.src = img.src is always a no-op per spec given the definition of "change" in http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#dom-trees Comment 20 also seems like a new spec bug. 102585 22 ian 2014-03-18 17:51:22 +0000 comment 5 is bug 24958. comment 20 seems like a core part of this bug, or at least a prereq. Sounds like I'll have to move the <img> section to that model before we can really figure out what to do for comment 0. 102639 23 zcorpan 2014-03-19 14:44:52 +0000 Yeah. 106317 24 zcorpan 2014-05-19 08:36:06 +0000 (In reply to Boris Zbarsky from comment #5) > The main hard web compat constraint here I'm aware of is that given a loaded > image, setting its src to the same value should check whether it's expired > (HTTP caching semantics) and if so reload the image. Gecko implements this > by just always forcing a load on src set; if there is an existing load > (whether done or not), it's dropped to make way for the new one. I can't get Firefox 26 to reload the image when setting src to the same value. Is the compat constraint just restarting the animation? As far as I can tell animations are restarted even if it's not expired. 106352 25 bzbarsky 2014-05-19 15:55:09 +0000 > I can't get Firefox 26 to reload the image when setting src to the same value. How are you determining that? Note that the "reload" will still follow HTTP cache semantics... > Is the compat constraint just restarting the animation? I don't believe so, given https://bugzilla.mozilla.org/show_bug.cgi?id=980243 106416 26 zcorpan 2014-05-20 02:31:37 +0000 (In reply to Boris Zbarsky from comment #25) > > I can't get Firefox 26 to reload the image when setting src to the same value. > > How are you determining that? Note that the "reload" will still follow HTTP > cache semantics... https://github.com/zcorpan/web-platform-tests/blob/img-bug-24711/html/semantics/embedded-content/the-img-element/update-the-image-data/set-src-idl-same-value-loaded-not-cacheable.html https://github.com/zcorpan/web-platform-tests/blob/img-bug-24711/html/semantics/embedded-content/the-img-element/update-the-image-data/resources/common.js https://github.com/zcorpan/web-platform-tests/blob/img-bug-24711/html/semantics/embedded-content/the-img-element/update-the-image-data/resources/stash-count-requests.py Review for the tests at https://critic.hoppipolla.co.uk/r/1593 So what the test is doing is that it loads an image with the headers: Cache-Control: no-store, no-cache, must-revalidate Expires: Tue, 19 Nov 1985 21:00:00 GMT Then, in img.onload, it does img.src = url_put; (which is the same value). The test counts the number of requests on the server side and I only see 1 request in Firefox 26 for this test. > I don't believe so, given https://bugzilla.mozilla.org/show_bug.cgi?id=980243 OK, thanks. (I also found https://bugzilla.mozilla.org/show_bug.cgi?id=183470 which seems related.) 106420 27 bzbarsky 2014-05-20 03:36:27 +0000 > So what the test is doing is that it loads an image with the headers: Is there a live version of the test somewhere I could take a look at? 106423 28 zcorpan 2014-05-20 05:39:35 +0000 http://w3c-test.org/submissions/996/html/semantics/embedded-content/the-img-element/update-the-image-data/set-src-idl-same-value-loaded-not-cacheable.html (When the PR gets merged in the future, remove "submissions/996/" from the URL.) 106541 29 bzbarsky 2014-05-21 06:25:26 +0000 Hmm. Looks like there's some deal in Gecko now that basically assumes non-HTTP semantics are OK as long as the document is the same... So maybe resetting animations (and perhaps firing load events; unclear) is all that's needed for compat. 106542 30 bzbarsky 2014-05-21 06:26:18 +0000 And thank you for the link, by the way! 107843 31 zcorpan 2014-06-16 10:45:45 +0000 Specify how parallel image fetching works. https://github.com/ResponsiveImagesCG/picture-element/commit/22efd4478d7714ac12fd128ca2c455d0f91f42a4 (Leaving open for comment 0.) 107861 32 zcorpan 2014-06-16 18:41:44 +0000 Reuse ongoing fetches in 'update the image data'. https://github.com/ResponsiveImagesCG/picture-element/commit/a67d019f75f95ec3552adc36376522059c582ccc