Jcrop v0.9.6 Released (Numerous enhancements)

A new version, Jcrop v0.9.6, is available today. This update includes some important feature additions and improvements.

A new version of Jcrop is available today with the following updates:

  • Jcrop widget can now be disabled, re-enabled, or removed entirely
  • New selections, moving, and resizing can now be disabled/enabled
  • minSize/maxSize now work with aspectRatio set (thanks for the patch, Matt!)
  • setSelect and animateTo now scale coordinate input on larger images
  • Documentation has been updated to reflect some of the new functionality
  • Added a new API demo to download archive and online demos page
  • Internal code restructuring, including additional commenting

So it’s still certainly not perfect, and there is more work to be done, but there are some important features included that I didn’t want to sit on for too long. Please let me know how it works for you!

Tags: ,

21 Responses to “Jcrop v0.9.6 Released (Numerous enhancements)”

  1. CorradoNo Gravatar wrote:

    Cool! Thank you for this new release. Works ok on Opera 9.

  2. SEOAdsenseThemesNo Gravatar wrote:

    Good to see you’re back. With an updated plugin that comes with all the features I’m so looking forward to. Man, what can I ask for more!

  3. SEOAdsenseThemesNo Gravatar wrote:

    I see that setSelect coord values now adjust precisely to explicit sizing method. No need to having coords calculated against a scale ratio before passing them to setSelect. Am I correct?

  4. adminNo Gravatar wrote:

    Yes. setSelect and animateTo API methods now scale the input coordinates properly if a scale exists. I edited the post above to reflect this, and I made some edits to the online documentation. I’m going to try to more comprehensively revise the documentation sometime in the near future.

  5. SEOAdsenseThemesNo Gravatar wrote:

    Thanks, I like it very much not having to pre-calculate coordinates in scaled images. And minSize playing nice with aspectRatio too.

  6. Graham WheelerNo Gravatar wrote:

    I’m seeing some nasty issues with the new version – targeted images disappear entirely in FF3 and in IE8 the image remains but clicking and dragging on the image yields no crop selection.

  7. DanielNo Gravatar wrote:

    Graham – That’s happening to me… this update basically made this plugin useless… completely remove my images when targeted, even with just the simplest $(“#cropbox).Jcrop()

    please update asap or I will have to find a different solution for production code.

  8. adminNo Gravatar wrote:

    @Graham – Very troublesome to hear this. Unfortunately I can’t reproduce this locally on any browsers or platforms that I have. I’m on the case!

    @Daniel – Obviously this would be a big problem; this is the first I’m hearing of it. I’ll issue an update as soon as I can identify the problem and the fix.

  9. DanielNo Gravatar wrote:

    I would also add that in FF3 all photos in the documentation, both on your website and in the download are very very small, like 20x20px…

  10. adminNo Gravatar wrote:

    I’ve tested on FF3.0.6/Linux, FF3.0.8/Windows, and on IE6/Windows. I’m not seeing any of these problems. Can you tell me the exact FF3 version and platform? I’d really like to see this happening… thanks!

  11. DanielNo Gravatar wrote:

    I’m on Windows XP FF3.0.8 – I’m narrowing down the problem to just after line 100 where you initialize your jquery object… $img is coming out of $origimg.clone() with a width and height of 0. I’m also using jQuery 3.2… could that be the problem?

  12. DanielNo Gravatar wrote:

    I can also report that if i assign $img.height and width to $origimg.height and width right after the clone(), everything works.

  13. adminNo Gravatar wrote:

    Thanks a lot for your help, Daniel. A critical issue is that the image has it’s intended dimensions when Jcrop is initialized. Sometimes this happens by accident based on how quickly the images load, so that could lead to intermittent behavior not linked to a particular platform or browser. Jcrop is supposed to mitigate these problems, but looking back over that code it’s a bit messy.

    Try placing the invocation within $(window).load(…) instead of the typical DOM-ready handler. Does that fix the issue?

  14. DanielNo Gravatar wrote:

    placing in $(window).load() does not fix the issue for me…

  15. DanielNo Gravatar wrote:

    I’ve found the source of the problem, and it is not browser dependent, but it is speed dependent, so testing on your localhost probably won’t reproduce the problem…

    when you clone(), you’ve created a copy of the dom objects in memory, but when you insert $img back into the page with the line:


    the html is reloaded, along with the image, i.e. the image actually loads again from the server.

    So when you reference $img.height() two lines down, the image hasn’t finished loading and isn’t properly in the dom yet, so height returns 0.

    I’ve solved it temporarily by going back to the last method of wraping $img with $div, although that creates problems for your destroy() function, which i solved somewhat along these lines:

    $test = $(‘div.’ + cssClass(‘holder’));
    $img.css({ position: ‘relative’ });

    which is certainly not optimal, but does the trick for me, and i’m not really using destroy() anyways, but disable() enable() are very useful thanks :)


  16. DanielNo Gravatar wrote:

    you can verify this by adding the line:

    $img.load(function() {console.log(“Loaded!” + $img.height())});

    right before


  17. adminNo Gravatar wrote:

    Daniel, you are very astute, thanks again for your help tracking this down. The reason I changed the attachment method slightly was because of the same problem using remove with the previous approach. So, it appears that the use of clone() is somewhat to blame. My understanding is that when an image fires it’s onload handler, you’d expect that all the other instances of this src location to be loaded. Is this not the case? Does a browser normally request the same resource more than once per page load, no matter the DOM manipulations? Are you running anything that changes the default cache operation of Firefox? Just curious, because I cannot reproduce this problem yet on fairly default configurations. I’m not testing on localhost but my internet connection is pretty zippy. What if you change boundx and boundy to be set from $origimg instead of $img a couple lines down?

  18. DanielNo Gravatar wrote:

    I don’t know enough about browser intricacies to say one way or another, but my understanding is that if you put in a new tag it will request a new image.

    Now, you may have that image in your cache, but there is still a trip to the server to find that out.

    As for your last question, yes, taking the width and height from $origimg works. I just set $img dimensions to $origimg dimensions after the clone():


    However, I still don’t like the $origimg.hide() method, because it causes a flicker while the original is hidden and the new is loading.

  19. AndyNo Gravatar wrote:

    Fantastic update – many thanks!

    A small problem, though… If you set the allowSelect to be false and the user clicks once on the resizing area (either the handles or on the sides of the crop area) and don’t resize it – literally just a click – then the crop area will disappear and they’d need to reload the page to get it back.

  20. SEOAdsenseThemesNo Gravatar wrote:

    Andy is right. Even with “allowSelect” TRUE, a click on the sides of the crop area makes it disappear but you can make it appear again.

    When it disappears, the coords all point to a single bottom-left corner.

  21. adminNo Gravatar wrote:

    Andy, thanks for finding that! I was unaware of that bug. I fixed it after several minutes of struggle, and have rolled fixes for some of these other issues into a new version, 0.9.7. Please try it out and let me know if you find anything else! (or if you don’t!) Thanks again, all!