Firefox not loading in Larger Images on resize

This may shed a little more light on the issue, as I just discovered this:

I have another Mac that was still on Firefox 12, and everything works great. I updated it to version 28, and again, everything worked great. But when it updated itself to the latest 42.0.1, images were once again not swapping.

-Nick

This is a confirmed bug in FF which has been worked around in the latest version of Picturefill. See: https://github.com/scottjehl/picturefill/issues/586. Try upgrading to the newest version of this plugin, which includes Picturefill 3.0.1 and see if that fixes the issue for you.

Joe

Well, now things aren’t working properly in any of the browsers. They seem to be partially working in Safari and Chrome, but they are grabbing the wrong size images, whereas before the plugin was working like a charm.

It appears as if my custom sizes array is now completely being ignored, but I may be incorrectly implementing things. But again, everything was working great in the previous version.

For the images inside the_content() I use this code to generate my sizes array:

add_filter( 'tevkori_image_sizes_args', 'benoit_custom_sizes', 10, 3);
function benoit_custom_sizes( $args, $id, $size ) {
    if ( $size == 'full' ) {
        $args['sizes'] = '(min-width: 768px) 62.2vw, 93.75vw';
    }
    return $args;
}

I found that in the previous version of the plugin, I was able to place this code at the top of a specific template and it worked great. Thinking that maybe that was causing the problem I moved that code to the functions.php file. Even then, I still get the default sizes array on all of my posts. I even tried deleting the existing image from the post and inserting it again, but that did not work either.

In addition to not using the custom sizes array for the_content() images, it also does not appear to be grabbing all of the image sizes for the srcset (although I’m not sure that it did before, I didn’t pay that much attention …). Basically, I’m using a full ‘Retina’ size image of 2048×2048, and then I have wordpress generate 1024×1024, 600×600, 300×300, and 150×150.

In Safari and Chrome, all of the sizes are included in srcset up to 1024. It is not including my 2048×2048 image in srcset, but it does grab it for src. Images are swapping (albeit with the wrong sizes array), but it is ignoring the largest size image when it should be using it at larger viewports on a retina display – I assume because it is not listed in srcset.

In Firefox, the only image size included in srcset is my 300w, and the only image that loads in is the 1024, even with cache disabled. No swapping is occurring at all.

Thanks again for all you hard work!

-Nick

Hi Nick,

Thanks for this report. On the first issue, it looks like some changes that we made to the content filter ended up breaking your custom filter. We’ll fix this backcompatibility issue in the next release, but I would suggest updating your filter to run on the new filter name that will be used in WP core in version 4.4, which currently would look like this:

add_filter( 'wp_get_attachment_image_sizes', 'benoit_custom_sizes', 10, 3);
function benoit_custom_sizes( $args, $id, $size ) {
    if ( $size == 'full' ) {
        $args['sizes'] = '(min-width: 768px) 62.2vw, 93.75vw';
    }
    return $args;
}

However, that filter hook name is likely to change again in the near future.

For the second issue you mentioned, we’ve added a filter to limit the largest size that will be included in srcset lists by default at 1600px. You can override this value by adding a filter to max_srcset_image_width like this, which would add the 2048px size only when the 1024px size is the original:

add_filter( 'max_srcset_image_width', 'benoit_max_srcset_image_width', 10, 2 );
function benoit_max_srcset_image_width(  $max_width, $size_array  ) {
    if ( $size_array[0] === 1024 ) {
        $max_width = 2048;
    }
    return $max_width;
}

You could also simplify that filter to always return a larger number that 2048px if you prefer.

Let me know if that helps.
Joe

Re:

add_filter( 'wp_get_attachment_image_sizes', 'benoit_custom_sizes', 10, 3);
function benoit_custom_sizes( $args, $id, $size ) {
    if ( $size == 'full' ) {
        $args['sizes'] = '(min-width: 768px) 62.2vw, 93.75vw';
    }
    return $args;
}

That’s using the new filter wp_get_attachment_image_sizes but the callback benoit_custom_sizes() is based on the old filter tevkori_image_sizes_args. That won’t work. wp_get_attachment_image_sizes expects a string, not an array. The variables that are passed to the filter are different too. The backward compatibility issue that we have to fix will only apply when the deprecated tevkori_image_sizes_args filter is used.

This should work:

add_filter( 'wp_get_attachment_image_sizes', 'benoit_custom_sizes', 10, 5);
function benoit_custom_sizes( $sizes, $size, $image_meta, $attachment_id, $image_src ) {
    if ( $size == 'full' ) {
        $sizes = '(min-width: 768px) 62.2vw, 93.75vw';
    }
    return $sizes;
}

You don’t need all the variables that are passed to the filter but I kept them in there for completeness. See also the inline documentation of the new filter.

This applies to version 3.0.0 of the plugin. As Joe already mentioned we are going to rename the filter and the order of the parameters because it also has been changed in WP core.

Hi guys, thanks for your replies.

I’ve added these two functions to my functions.php and I’m still getting the default sizes array of “(max-width: 2048px) 100vw, 2048px” and the 2048w URL still isn’t listed in my srcset. I just double-checked and I’m running version 3.0.0 of the plugin.

add_filter( 'max_srcset_image_width', 'benoit_max_srcset_image_width', 10, 2 );
function benoit_max_srcset_image_width(  $max_width, $size_array  ) {
    if ( $size_array[0] === 1024 ) {
        $max_width = 2048;
    }
    return $max_width;
}

add_filter( 'wp_get_attachment_image_sizes', 'benoit_custom_sizes', 10, 5);
function benoit_custom_sizes( $sizes, $size, $image_meta, $attachment_id, $image_src ) {
    if ( $size == 'full' ) {
        $sizes = '(min-width: 768px) 62.2vw, 93.75vw';
    }
    return $sizes;
}

I made a mistake, sorry. When we filter the content and call wp_get_attachment_image_sizes() we don’t pass the size name but a size array to the function and its filter. That has to do with performance.
So it should have been:

add_filter( 'wp_get_attachment_image_sizes', 'benoit_custom_sizes', 10, 5);
function benoit_custom_sizes( $sizes, $size, $image_meta, $attachment_id, $image_src ) {
    if ( $size[0] === 1024 ) {
        $sizes = '(min-width: 768px) 62.2vw, 93.75vw';
    }
    return $sizes;
}

I hope that works.

I have no idea yet why the 2048×2048 isn’t included in the srcset. The code for the max_srcset_image_width looks good.

Well, I got it to work in Chrome …

I had to replace “1024” in both your and Joe’s functions with 2048 since that is the size of my ‘full’ image, but doing so got it to where I now have a srcset with my 2048w image included, and my custom sizes array is now being used.

However, in Safari all that will display now is the 2048 image even with cache disabled. It seems like it should be working the same as Chrome though, since I’m getting the same srcset and sizes (albeit as data-pfsrcset in Safari).

Firefox still only displays a 1024px image. It is using the correct sizes array though, and srcset now only includes my 2048w image instead of the 300w like it did before.

-Nick

Just a bit of an update – it turns out mobile Chrome is also only displaying the 2048×2048 image when I update max_srcset_image_width. It appears to first load in the 1024×1024 image, and then quickly swaps it out to 2048×2048. But with the function disabled, it only loads in the 600×600 image.

The desktop version is working properly.

I am glad you now get the expected responsive image markup. Personally I would use the SD image (1024×1024) as original source, because that’s the fallback if for some reason responsive images don’t work. You can use the image_size_names_choose filter to add image sizes to the select menu in the media library.

Regarding the problems you mention. It’s a bit hard to tell if it’s actually a browser/Picturefill issue without knowing more about the devices that you test on (screen resolution, SD or HD/Retina, etc.).

For mobile I’m testing on an iPhone 5 and iPhone 6, using iOS 9.1 with the latest Chrome and Safari. For desktop, I’ve tested on a 24-inch iMac (Early 2009) running Yosemite 10.10.5 with the latest Chrome, Safari and Firefox, and on a 27-inch Retina iMac (Late 2014), also on Yosemite 10.10.5 with the latest Safari, Chrome, and Firefox. And that’s just regular stable vanilla Chrome in all cases, not Canary.

Thanks,

-Nick

Hi Nicholas,

This thread now contains a lot of information about issues with various browsers on various devices. That makes it a bit hard to understand what is happening where and to determine if that’s a browser/Picturefill bug or not.
Do you have a test site online, or only local?

It’s only local right now. I know that doesn’t help much :/