After updating to Chrome 60, a specific image fails to lazy load
Reported by
ja...@mackweldon.com,
Aug 7 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36 Steps to reproduce the problem: 1. Go to www.mackweldon.com 2. scroll to bottom of page 3. lower left area has whitespace where an image should appear (the image should say "Buy More Save More") the image's location is at //d24mzuwd6is28u.cloudfront.net/content_image/23228/original/Buy_more_486_optimized-min.jpg?1500921692 The image loads fine when access directly Note that this is loaded via a lazy-loader, our image tag looks like so: <img src="" class="lazy" data-original="//d24mzuwd6is28u.cloudfront.net/content_image/23228/original/Buy_more_486_optimized-min.jpg?1500921692" alt=""> We have some javascript that does this to dynamically move what is in data-original into src: $("img.lazy").lazyload({ threshold : 200, effect: "fadeIn" }); What is the expected behavior? All 3 images should appear correctly. What went wrong? PLEASE NOTE: This problem was definitely introduced in Chrome 60, symptom not present in lower versions of Chrome. Interestingly, it affects ONLY this image on the page -- all other images on the page are lazy loaded correctly. Did this work before? Yes 59 Chrome version: 60.0.3112.90 Channel: stable OS Version: OS X 10.12.5 Flash Version: We are still debugging this to determine why only this single image does not lazy load correctly. Please note that our home page changes almost daily, so if we fix this on Production it may not be reproducible. If I am able to fix it, I will post here what the root cause is.
,
Aug 7 2017
,
Aug 8 2017
Thanks for the bug report, I can reproduce the same loading failure on Linux M60 as well, so this may happen on any platform. Could you make minimized test case, if any, or keep the snapshot of failing version somewhere?
,
Aug 8 2017
jason@ - Thanks for the issue Able to reproduce the issue on Windows 10, Ubuntu 14.04 and Mac 10.12.6 using chrome stable version #60.0.3112.90 and latest canary #62.0.3179.0. Bisect Information: ===================== Good build: 60.0.3078.0 Revision(466494) Bad Build : 60.0.3079.0 Revision(466571) Change Log URL: https://chromium.googlesource.com/chromium/src/+log/32d9f5075ba7f767d2c6c6d41794dc70b5ff7bf3..fe767186a3dc40ea14b5f807ff5438bd78f79c95 From the above change log suspecting below change Review URL: https://codereview.chromium.org/2593263003 robhogan@ - Could you please check whether this is issue is related to your change, if not please help us in assigning it to the right owner. Thanks...!! Note: cc'ing manoranjanr@ and bustmante@ for review and if this can be considered as stable blocker if we plan any refresh.
,
Aug 8 2017
Setting as Blink>Layout as the bisect points at an issue from that component.
,
Aug 8 2017
dtapu...@chromium.org : Thank you for investigating! Please note: because it affects only a single image on our web page, we suspect there is something corrupted with that image. If so, we can likely repair our home page ourselves of course. Nonetheless, the fact that Chrome 60 now behaves differently than Chrome 59 (in whatever to-be-determined way it does) does indicate there was some kind of regression in Chrome. However, given that it is likely specific to a particular image, it would be reasonable to consider this a NO-FIX if indeed the problem can be fixed by web developers (that's your call, of course). Nonetheless, I wanted to report it so there's a record. When/if I do identify the problem, I will *also* create a Stack overflow post to illuminate the issue for the developer community. We will debug our page to see if we can figure out why only this single image is the problem. Will post update here if we figure it out.
,
Aug 10 2017
Hi Jason - when I load the page with devtools open it looks to me like Buy_more_486_optimized-min.jpg is not being requested, it doesn't show up in the network log for example. Requests for the other resources do appear, e.g. Love_it*.jpg. Would you be able to troubleshoot the lazyload a bit further and see why it ends up not happening?
,
Aug 10 2017
,
Aug 10 2017
I narrowed this down to improperly specified image tags via our lazy loader. SUMMARY OF ROOT CAUSE: We are using jquery Lazy load version 1.9.3, which can be seen here https://github.com/tuupola/jquery_lazyload/blob/1.9.3/jquery.lazyload.js The issue was incorrectly formatted img tags, they contain src attributes of empty string, like such: <img class="lazy" src="" data-original="example.jpg" alt=""> (notice src is set to empty string) The correctly formatted tags are without an src attribute, as the image's source is managed (first via a placeholder with a delayed load of the image): <img class="lazy" data-original="example.jpg" alt=""> EXPLANATION OF ISSUE RELATED TO jQUERY LAZY LOAD As you can see here in the code: https://github.com/tuupola/jquery_lazyload/blob/1.9.3/jquery.lazyload.js#L92 The intention of the code as per the placeholder functionality (shown here) is for there to be no src arrtibtue, e.g., to be equal to undefined or false. The actual line of code that cuases the problem is not 92, however, it is later here: https://github.com/tuupola/jquery_lazyload/blob/1.9.3/jquery.lazyload.js#L99 in Chrome 59, the improperly formatted tags (with src="") triggered an 'appear' event In Chrome 60, they do not trigger an 'appear' event, so the callback attached to line 99 does not run. The root cause of this issue was improperly formatted html in conjuction with a specialized tool. Therefore I recommend no-fix/no-action to the Chromium team. I will leave this document for other developers' refernece and notify the author of jQuery Lazy Load. Thanks!
,
Aug 13 2017
Thanks for getting back to us! |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ja...@mackweldon.com
, Aug 7 2017