UnigramDev/Unigram/develop • 7a026d5 • 3 files, +14/-5
Read the name, not FileType, to know what a file is

A file dragged straight out of a ZIP archive arrives with an empty FileType,
though its Name still carries the extension. HasExtension compared FileType and
so answered false for everything in one.

That decided more than it looks. StorageMedia.CreateAsync dispatches on it
before probing, so a photo out of a ZIP fell through to StorageDocument and was
sent as a file: no thumbnail, no album, no compression. GetItemsView uses it for
the WEBP split that works around the server ignoring force_file inside an album,
so a WEBP out of a ZIP would have stayed in its album and failed the whole
upload -- the exact failure that workaround exists to prevent. GenerationService
uses it to pick the audio generation mode.

HasExtension now falls back to Name when FileType is empty, rather than always
reading Name, which keeps the exact-match behaviour everywhere FileType is
populated. It cannot turn a correct false into a true either: a file with no
extension has none in its name.

Two more places read FileType directly and had the same blind spot.
MessageFactory decides whether a WEBP might be a sticker and whether a TGS
might be an animation. EditMediaPopup decides whether to open the trim toolbar
or the crop one, which meant a video out of a ZIP got the photo editor and
InitializeVideo never ran. Both go through HasExtension now.

EditMediaPopup's matters twice over: ImageHelper.OpenReadAsync already carries a
comment saying it and EditMediaPopup must agree about what a video is, and
fixing only HasExtension would have made them disagree for exactly these files.

The remaining FileType reads are TDLib's StorageStatisticsByFileType and
NetworkStatisticsEntryFile, which are unrelated types.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UnigramDev/Unigram/develop • b5cdb0e • 1 files, +4/-3
Say what the trim strip scales to

Math.Max(ratioY, ratioY) compares a value with itself and ratioX above it was
computed and never used, which reads like a typo for Math.Max(ratioX, ratioY).
It is not one, and making that change would break the strip.

The 40 is the height of the filmstrip, not a box to fit inside. Each frame is a
Border in a row of grid columns filling 296 pixels, so it has to be 40 tall
with its width following the aspect -- which is what dividing by pixelHeight
gives. Taking the larger ratio would pin a portrait video's width to 40 instead
and leave every frame taller than the strip.

So the scale is written as what it is, and the dead ratioX goes with the
no-op Max.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

#unigram