App
App copied to clipboard
Expensify
[Image] Web - Profile - The white background in the image changes to black
If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!
Action Performed:
- Go to URL https://staging.new.expensify.com/ and login with any account
- Go to Settings->Profile->Upload photo
- Select an image with a white background and click save
Attachment:
Expected Result:
The background on the avatar should remain white
Actual Result:
The white background changes to black
Workaround:
Unknown
Platform:
Where is this issue occurring?
- Web
- iOS
- Android
- Desktop App
- Mobile Web
Version Number: 1.2.1.0
Reproducible in staging?: Yes
Reproducible in production?: Yes
Email or phone of affected tester (no customers): any
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/93399543/190678241-6ef6d543-ecf5-491c-87cd-ec57b6df3b86.mp4
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Triggered auto assignment to @tgolen (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.
![melvin-bot[bot] avatar](https://avatars.githubusercontent.com/in/179547?v=4 "Published by a pub.dev verified publisher"){kind=small}
It's not an issue, it happens because the background is transparent. The result will be the same if we try it on other platforms (e.g. Slack, Whatsapp)
Shouldn't the transparent background remain transparent though? Is this because it's being converted to a JPEG at some point (and transparency isn't supported)?
It seems like the backend is removing the transparency after processing the image.
Yes, while saving, image is converting jpeg and jpeg doesn't support transparency.
All right, sounds like this would be an internal issue for us to fix then on the server. It would be nice to support images with transparent backgrounds.
Triggered auto assignment to @MitchExpensify (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.
@MitchExpensify I reproduced with the image provided in the OP:
I reproduced in web, production
Assigning myself too & making Weekly since this is on hold for the image enhancements
Alright well I have some (maybe) interesting findings:
- It looks like we hardcode the
jpgfile type in NewDot here while for native devices we hardcode a.jpgat the end of the filename but set the "type" asimage/pnghere - On the server side we also basically force every uploaded file to be converted to a
jpeghere
So I believe we'll have to do this in 2 parts:
- ✅ Web-E: https://github.com/Expensify/Web-Expensify/pull/35442
- ✅ Follow-up 🤫 : https://github.com/Expensify/Web-Expensify/pull/35489
- App: https://github.com/Expensify/App/pull/12549
@Beamanator Quick question: Why aren't we adding support for .svg avatar uploads in this issue?
@JmillsExpensify good question! Currently it looks like we block .svg images from being uploaded as avatars here: https://github.com/Expensify/App/blob/0c65dbef1e97c6b811760b97e32a566e26b2e000/src/CONST.js#L30
I'm definitely willing to try to support .svg if we want though!
Ok yeah it's come up in a couple of contexts, in https://github.com/Expensify/App/issues/12264 most recently. It's fine if it's a separate project. I'm not clear why we block that file type in the first place.
Aah interestingggg, I'm happy to make it another issue in my tracker, though maybe a bit lower priority
Updated: added (& linked below)
Final PR for this (https://github.com/Expensify/App/pull/12549) is ready for review!
Issue not reproducible during KI retests. (Third week) Are we ok to close this one?
Haha I'm still able to reproduce this issue with a transparent PNG :D Hoping to continue the App PR today!!
Found some annoying issues on Mobile where Android & iOS Native Apps don't properly handle bmp & gif file uploads (with the help of @Santhosh-Sellavel 's very thorough tests 👍 ) 🤷 so I'm planning to make a follow-up issue (https://github.com/Expensify/App/issues/13038) that's external where others can help investigate possible solutions in the 3rd-party library we use, @oguzhnatly/react-native-image-manipulator
Note: We "could" consider this a feature request which would put that follow-up on hold? Or, since it's very closely related to this current issue which we consider WAQ, maybe no hold needed 🤔 Thoughts @JmillsExpensify @trjExpensify ?
Great question. This is a bit of a grey area, since we recently added the ability to support all file types, which pre-dates WAQ. So based on that, given that we now support all file types and we have bugs related to that, I think we should solve them now as part of WAQ.
That's fair, hopefully the PR to support all file types (for web / desktop / mobile web) will get merged soon, then I'll take the issue to fix bmp / gif images off HOLD, and we can get to work on it (probably from contractors since it seems like a big refactor that'll require updating at least 1 3rd-party lib)
Ok cool. That sounds like a plan to me. I think we should put this issue on HOLD in the meantime in any case.
Wait wait taking this off hold b/c https://github.com/Expensify/App/pull/12549 is the PR to fix this issue :D (or am I missing something @JmillsExpensify )?