We should not rewrite <img src=... width=1 height=1> to 1x1

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Add a <img src=... width=1 height=1> where src is *not* a 1x1 image
2. It is rewritten to a 1x1 image
3. The intention was probably to preload the image into browser's cache, we 
have now circumvented the trick.

Ex: http://www.magentocommerce.com/

However, what we should do is not exactly clear. We don't want to leave the 
original URL, because then the user would load 2 images, one original, and one 
rewritten later in the page. We could guess how the later image was going to be 
rewritten (recompressed, but not resized) and do the same thing here...

Original issue reported on code.google.com by sligocki@google.com on 13 Jul 2011 at 10:05

[GoogleCodeExporter]

In this case it seems like we'll get an OK result if we just skip the resize 
for img tags with style="visibility:hidden;"

It seems like those images are likely to not be resized when fetched later, so 
if we just let them be cache-extended in this case (if needed) that should have 
reasonable results.

Original comment by jmara...@gmail.com on 13 Jul 2011 at 10:19

[GoogleCodeExporter]

Speaking of which, looking at inline style="..." is on the RFE for images (we 
can stash dimensions there, and they're stickier than width= height=).  It'd be 
interesting to know how common the various image prefetch hacks are:
1) 1x1 or 0x0 img tag (easy to optimize as if it was mentioned at its natural 
size)
2) style="visibility:hidden", applicable CSS rule with visibility:hidden:  
We'll end up optimizing this at its natural dimensionality.  Not 100% obvious 
that any given browser will actually prefetch hidden images, but I think most 
do on the assumption that JS code will make them visible at some point.
3) link rel=prefetch and relatives: We don't currently do anything with images 
reachable from such links.  There's no real content-type distinction here, so 
we'd have to do content-based dispatch to decide if any of our optimizations 
apply.  It might be worth it anyhow, as this sets fetch priority correctly.
4) img element creation in javascript: We can't optimize this at all, and it 
might end up fetching original resource urls that we then rewrite in the target 
page---causing us to load two copies of basically the same image data (original 
and rewritten / cache extended) under two urls.  Sadly I suspect this is the 
most widely recommended technique.

Original comment by jmaes...@google.com on 14 Jul 2011 at 2:09

[GoogleCodeExporter]

Current plan is to disable image resize when resulting area <= 1x1.  This 
preserves prefetch behavior in this special case (and should be what we want, 
since any image shrink to this size should be a deliberate prefetch attempt).  
We will still rewrite the image, on the assumption that the image being 
prefetched will ultimately occur in an optimizable context.

Note, however, that there are better ways to prefetch images than 1x1 invisible 
<img> tags.  In particular, if you're going to fetch the image via JS code (tag 
injection or AJAX request) you should prefetch it the same way to ensure that 
the level optimization for your prefetch matches the ultimate fetch request.

Original comment by jmaes...@google.com on 10 Dec 2012 at 8:44

[GoogleCodeExporter]

Original comment by jmaes...@google.com on 10 Dec 2012 at 8:44

• Changed state: Started

[GoogleCodeExporter]

Fixed in r2435

Original comment by jmaes...@google.com on 28 Jan 2013 at 8:07

• Changed state: Fixed
• Added labels: release-note