Cannot upload a profile picture

[phil-davis]

Steps to reproduce

1. create a user and login
2. go to Settings, General
3. try to upload a profile picture using the "Upload new" icon (I tried using a JPG file that was 67.5Kb)

Expected behaviour

The picture should upload, and be displayed as the icon of the user's profile.

Actual behaviour

The POST request to upload the picutre gets 400 bad request status returned:

[Fri Jul 24 20:19:21 2026] 127.0.0.1:44906 Accepted
[Fri Jul 24 20:19:21 2026] 127.0.0.1:44906 [400]: POST /index.php/avatar/cropped
[Fri Jul 24 20:19:21 2026] 127.0.0.1:44906 Closing

I don't get anything logged in owncloud.log

Server configuration

Local development environment with git clone of owncloud/core and rfunning a PHP dev server.

Similar happens using the 11.0.0-rc2 docker image.

[phil-davis]

The same happens if I first upload the JPG image using the Files app, then use the "Select from Files" icon to try to select it as the profile picture.

[DeepDiver1975]

Root cause

Two bugs combine here, both in the avatar/cropper flow:

1. Primary cause — Jcrop 2.0 asset rename (→ #41724)

#38666 bumped the bundled Jcrop from 0.9.12 to 2.0.4. Jcrop 2.0 renamed its distribution files:

• js/jquery.Jcrop.js → js/Jcrop.js
• css/jquery.Jcrop.css → css/Jcrop.css

but settings/templates/panels/personal/profile.php still loaded the old paths, so the script 404s and $.fn.Jcrop is never registered. In the browser this is the $cropperImage.Jcrop is not a function error. Because Jcrop never initializes, its onChange/onSelect callbacks never fire, so $('#cropper').data() has no x/y/w/h and clicking Choose as profile picture POSTs empty coordinates (crop[x]=&crop[y]=...).

Fixed in #41724.

2. Secondary cause — controller doesn't validate crop coordinates (→ #41725)

With empty coordinates, postCroppedAvatar passes them into round() / OC_Image::crop():

• On PHP 8 round('') throws a TypeError → HTTP 500 (logged).
• On PHP 7 (the 11.0.0-rc2 docker image) round('') returns 0.0, imagecreatetruecolor(0, 0) fails → broken crop and a clean HTTP 400 with nothing logged — the symptom you saw.

I reproduced the whole login → upload → crop flow against a live instance to confirm both paths.

#41725 adds a numeric-coordinate guard so malformed crop data returns a clean 400 instead of crashing, independent of PHP version. Once both PRs land this is fully resolved.