[GH-ISSUE #1377] [Bug] Crash while moving cropping handles via Insert Frames dialog #3610

Closed
opened 2026-03-01 19:13:57 +03:00 by kerem · 0 comments
Owner

Originally created by @ThinkAndWander on GitHub (Mar 17, 2025).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/1377

Originally assigned to: @NickeManarin on GitHub.

Crash

Moving the cropping handles in the Insert Frames dialog (Insert.xaml), shown below for reference:

Image

results in unexpected behavior that sets the dimensions to extraordinary values
Image

which can actually crash once it represents infinity in floating point. It gets here fast; I got it naturally i.e. I was not trying to replicate bugs.
Image

To Reproduce
Steps to reproduce the behavior:

  1. Click Load, choose a frame
  2. Click Media, add another frame that knowingly does not match the same height
  3. Click the bottom cropping handle and drag it downwards just a bit, then wiggle the mouse in place
  4. Observe the dimensions run to infinity very quickly

Expected behavior
Cropping handles should move normally, of course. None of this craziness :p

Desktop (please complete the following information):

  • OS: Windows 10 Home
  • Version 19045.5247
  • OS and Monitor Resolution match, 1920 x 1080 native

Sidenote

There are several issues with this dialog. It's just very hard and confusing to use, almost everything it does with the cropping handles is surprising. I don't know if other behavior I found is a bug or not, but it would crop the image size as well in the new frame when I attempted to move a handle once, (it reflected a new size under "Image Size") and there's no undo/redo for it.

Originally created by @ThinkAndWander on GitHub (Mar 17, 2025). Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/1377 Originally assigned to: @NickeManarin on GitHub. ## Crash Moving the cropping handles in the Insert Frames dialog (Insert.xaml), shown below for reference: ![Image](https://github.com/user-attachments/assets/f3efbe4e-4ed5-4e6d-beff-1d0c0f0f6f4d) results in unexpected behavior that sets the dimensions to extraordinary values ![Image](https://github.com/user-attachments/assets/2cfa80dd-bb80-424f-8de0-196d700841f9) which can actually crash once it represents infinity in floating point. It gets here fast; I got it naturally i.e. I was not trying to replicate bugs. ![Image](https://github.com/user-attachments/assets/334f73b0-3ad8-49cd-a239-c9b32114b8ca) **To Reproduce** Steps to reproduce the behavior: 1. Click Load, choose a frame 2. Click Media, add another frame that knowingly does not match the same height 3. Click the bottom cropping handle and drag it downwards just a bit, then wiggle the mouse in place 4. Observe the dimensions run to infinity very quickly **Expected behavior** Cropping handles should move normally, of course. None of this craziness :p **Desktop (please complete the following information):** - OS: Windows 10 Home - Version 19045.5247 - OS and Monitor Resolution match, 1920 x 1080 native ### Sidenote There are several issues with this dialog. It's just very hard and confusing to use, almost everything it does with the cropping handles is surprising. I don't know if other behavior I found is a bug or not, but it would crop the image size as well in the new frame when I attempted to move a handle once, (it reflected a new size under "Image Size") and there's no undo/redo for it.
kerem 2026-03-01 19:13:57 +03:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/ScreenToGif#3610
No description provided.