Broken avatar on GHE (again)
🔍 Is there already an issue for your problem?
- [X] I have checked older issues, open and closed
📝 Description
In a GHE situation, avatars for users are broken. This seems similar to #564 but in fact is not.
Looking at the inspector tab, the src for the image is correctly populated and points a valid image if I open it from my browser.
Incidentally, I have an amount of warnings as
reading cookie in cross-site context will be blocked in future Chrome versions
Whether that's the real problem or not...I am yet to understand. I cannot find any other error.
🪜 Steps To Reproduce
- Use in a GHE context
- GHE is 3.11
Gitify Version
5.7.0
Operating System
macOS
GitHub Account
GitHub Enterprise
📸 Screenshots
thanks for reporting @LunaticMuch
so to confirm, the avatar url returns a valid image, but renders as broken 🤔
so to confirm, the avatar url returns a valid image, but renders as broken 🤔
Yes. I checked the code, the console, but I can get my head around it. I only suspected the cookie, but also I cannot see the "relationship"
Puzzling indeed... together I'm sure we'll get to the bottom of it 🤝
Any chance you are able to run gitify from the source code to see if that has the same issue? 🤞
git clone
pnpm i
pnpm watch
pnpm start
I also wonder whether there's a network request for the image at all? Maybe there's a security policy that prevents the loading, for instance. Would need @LunaticMuch to check that, I don't have GHE to try to repro
@setchy and @bmulholland I can definitely help... give me a bit, feels more a debug I need to squeeze after work 😄
@setchy and @bmulholland I can definitely help... give me a bit, feels more a debug I need to squeeze after work 😄
absolutely! thank you again @LunaticMuch 🙇
First debug session, following your guidance @setchy
- Console is empty. There's no reported error or warning. Actually nothing at all.
- I do not see any call for the image tracing the network... this quite interesting, but it feels weird the security policy. If the connection is not started, this should not be related to a policy. The policy might block the response, not opening a socket for the call
Looks like you have Detailed Notifications enabled. In that case, you'll find the logic within src/utils/subject.ts that enriches notifications with the most recent SubjectUser (logic varies by notification type ie: Issues vs PullRequests vs Discussions, etc)
I need to dig into that, but from my initial testing, it's all fine. Actually, the repo icon suffers of the same problem, but the default icon for the runners does not 🤔
The default icons used for workflows (and as a default when no avatar available) are from the primer/octicons package
Perhaps a fix lies in setting the crossorigin attribute on the img tags...
https://www.geeksforgeeks.org/how-to-allow-cross-origin-use-of-images-and-canvas/
@LunaticMuch - when you said these urls load in a new tab, was that in an incognito/private or a regular instance?
@LunaticMuch - just wanted to confirm if you're still experiencing this issue?
Closing as stale. Happy to reopen if others report more details to help triage
I can confirm the issue still occurs as of today
@mislavperi - are you able to share further details please, such as Gitify version, GitHub account type(s), OS type. Any log screenshots would also be useful (via Developer Tools network console or app log file)
@setchy Yes I'll get you those today
Perfect!
I've also been wondering if these broken avatars also occur on this feature branch which uses the official GitHub Primer avatar components
https://github.com/gitify-app/gitify/pull/1589
@setchy
Account type enterprise account, we run on GHE 3.13.3
Running MacOS Sonoma 14.3
Gitlify version is v5.16.1
It also seems to be stuck on high number of notifications (I can't clear them at all) and new ones never come
Here are the inspect element network tab and console errors I get
HTTP 302 hey... So is there a suggested new location?
If you get the chance to test Gitify locally using that branch I shared, I'd love to hear if this is natively resolved within the GitHub component library
@setchy
Still the same. I'm also struggling to open the inspect element for some reason
Thanks for testing the branch @mislavperi. 🙏
Back to the drawing board then 😅.
I'm curious if this happens for ALL GHE users or a smaller cohort 🤔
Let me know if you need any help @setchy
We'd love a hand @mislavperi since none of the maintainers are able to recreate this bug and find an effective solution. If you are able to spend some time digging deeper that would be greatly appreciated.
As an aside, I've been thinking about interim "hacks" to address the broken avatar images experience which is not ideal... perhaps we should use the default GitHub Mark Icon avatar (either for ALL GHE accounts, or, through a user setting)... at least until we find the root of the issue
@pddg - as a GHE user, do you also have this broken avatar issue?
The avatar image was corrupted when a problem occurred connecting to the GHE Server. Even if the connection is restored, it image will not be restored immediately. However, it will be displayed normally at some point.
Open/Close window, reload manually does not help. Open settings and return to the notifications list will recover the avatar image. I hadn't really thought about it before, so there may be other cases where it is restored.
Ah ha, that's helpful insight @pddg.
@setchy In my case, it refuses to connect after initial configuration was defined, I'll spin up the instance locally and see why it might be happening
Sorry for my long absence, but I found generally that loading avatars with GHE is generally a big pain https://github.com/microsoft/vscode-pull-request-github/issues/416 I found other countless threads that showcase the same issue. Do you maybe want to introduce fallback icons in case there is a 302?
Thanks @mislavperi - that's really interesting research you found.
I like the idea of adding some fallback logic to use a default icon. We have some similar logic for when a user profile doesn't have an avatar at all, so perhaps we can extend that for this unique use-case
@mislavperi - is this something you'd be interested in contributing back?