Hard limit + floating point issue

Created on 22 June 2020, about 5 years ago
Updated 4 September 2025, 10 days ago

## Problem
If you use hard limit for a crop type, then there is a chance that when you drag and drop the crop area to the limit, that image widget crop internally uses the image size instead of the actual selected crop size. The problem is that due to floating point issues, it's actually possible to select an area smaller than the limit, which than translates into a selection the entire height/width.

## Steps to reproduce
1. Create an odd sized hard limit, fx 1392 px
2. Upload a big image, fx 2500 x 2500
3. Crop the image with the minimum possible selection.
4. Save
5. Observer that the crop saved does not reflect what you input, height/width has max value.

๐Ÿ› Bug report
Status

Needs work

Version

2.0

Component

User interface

Created by

๐Ÿ‡ฉ๐Ÿ‡ฐDenmark googletorp

Live updates comments and jobs are added and updated live.
  • JavaScript

    Affects the content, performance, or handling of Javascript.

  • 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

Comments & Activities

Not all content is available!

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

Production build 0.71.5 2024