Crop widget not adjusting crop box when crop is applied

Created on 17 May 2021, almost 4 years ago
Updated 12 September 2023, over 1 year ago

Problem/Motivation

When I use the cropping widget, after I save and reopen a media item, the crop box reverts back to the default position instead of where I set the crop. I'm not sure if this is a bug or if I'm just missing a setting or something so feel free to update the category if need be.

Steps to reproduce

  1. Create a crop
  2. Go into media item and adjust the cropbox
  3. Save
  4. Reopen the media item and crop box is reset to the default position instead of where I manually moved it to
πŸ› Bug report
Status

Needs work

Version

2.0

Component

User interface

Created by

πŸ‡ΊπŸ‡ΈUnited States rosemarystanley

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡§πŸ‡ͺBelgium kriboogh

    Linking both issues for visibility.

  • πŸ‡³πŸ‡±Netherlands eelkeblok Netherlands πŸ‡³πŸ‡±

    Linking πŸ“Œ Fix coding standard issues + add GitLab CI to the project Needs review as it fixes the test that I guess needs to be extended to fulfil #15.

  • πŸ‡³πŸ‡±Netherlands eelkeblok Netherlands πŸ‡³πŸ‡±

    I've found this patch can actually also run into a floating point issue; on certain image sizes, the dimensions of the crop area may work out to be slightly larger than the preview image used for the cropping, in which case Cropper will decide to show the default crop area. I'll see if I can work up a reproduction case and an updated patch.

    When granting credit, please also include @idebr at iO since he actually found this issue.

  • πŸ‡³πŸ‡±Netherlands eelkeblok Netherlands πŸ‡³πŸ‡±

    Here's a file that can be used to reproduce the problem mentioned above. It works with the default 400 wide cropping thumbnail. I didn't dive into the exact mechanics how the width ends up being larger that the available width, but it obviously is some sort of rounding error. Intuitively, I'd say a simple round should be enough to get it back to 400 instead of 400-point-something, I can't imagine the rounding error would be large enough to get it up to 401. The alternative would be to do a floor, but that would work out to 399 (as long as we're sticking to the default cropping preview for the example) in a significant number of cases.

    Also, I am wondering why we need extra lines of code to pass this information to the cropper; it would seem this is already happening somewhere else, so isn't it possible to leverage that in this particular case. The solution seems a bit "smelly", but maybe I am misunderstanding the problem.

  • πŸ‡«πŸ‡·France dqd London | N.Y.C | Paris | Hamburg | Berlin

    Thanks for the awesome and helpful review @eelkeblok - Seems this still neds work. Just wanted to let know that some of the required issues linked have been committed know. So wrk can go on in here. +1

  • πŸ‡«πŸ‡·France dqd London | N.Y.C | Paris | Hamburg | Berlin
  • Pipeline finished with Success
    4 months ago
    Total: 193s
    #344598
  • πŸ‡³πŸ‡±Netherlands eelkeblok Netherlands πŸ‡³πŸ‡±

    I updated MR !3 with a fix for the problem because I needed a solution for the time being. Leaving on Needs work for the feedback about whether we need an additional place to set these dimensions, or whether we should be looking into where the dimensions are applied when it does work and whether we can make adjustments to make that work. It seems that we are now introducing some duplicate code that could have similar bugs. I tried finding out how it works for other situations, but couldn't figure it out in the limited time I had available.

Production build 0.71.5 2024