This is concerning. It's certainly not ever been bulletproof but it shouldn't be failing out anywhere near every time (the Type Error is I think, expected when reloading while a request is in progress, but I'm assuming you reload because otherwise it never successfully posts?) Any further errors you can share? the developer console/network tab can show a lot of useful details but I'm not even sure where to start with this one. OS and browser details, I guess?

edit: and this comment posted pretty much instantly for me, using a firefox fork on a like 4 year old linux box

When you refer to the emote picker, do you mean the one that pops up when you start typing out the shortcode (e.g. :fidel ) or the one above the text input box under the little smiley icon?

Both have performance issues to some degree, but there probably isn't much you can do on your machine about it. Maybe there's some sort of extension that can force cache them? It's something we've tried addressing from the server side in the past with limited success, but it could use more work.

I have a likely culprit on this, working on a fix to test out.

Thanks for the heads up. Will look into it.

Did this just start today?

Sorry gamers, there's been an ongoing denial of service issue, and then a bungled code deploy today. Hopefully will be a bit more stable going forward.

Agreed on IZ, that emote has been renamed :iz-shaka: (and tagged appropriately so it's hopefully still findable)

The rest is tbd, thank you for your efforts making it, and your patience!

(Note: this is not in any way an official statement by the admin team, I'm just a tech dweeb)

Proposal: Do Nothing, but improve searchability by making the shortcode autocomplete also search by tags, not just the canonical name.

We have the ability to add basically unlimited alt-names or descriptors to the tags for each emote, which has made searching in the emoji picker much more viable even for obscure emotes (provided they are well-tagged). Problem is, nobody uses the emoji picker, most people don't even know it exists.

Make sure the library is reasonably well tagged and make that tweak to the searching and this whole conundrum goes away.

Examples below of some existing tags from a previous effort to tag all the emotes:

We might also want to make the alt-text more descriptive for people with screen readers but that's a separate conversation

Edit: Oh it looks like a dev (comrade makotech222) has already chimed in on this below:

also, its maybe possible we can enhance the inline emoji window to use keywords as well. would have to do some experimentation with it.

 

secondary option if this isn't feasible: remove the unicode emojis from the emoji picker so it goes straight to our custom emotes when opened, and make it more prominent in the UI somehow (highlight it in a different color, make it bigger, make it sparkle, idc). And still finish the job tagging them all

As others have mentioned, that was implemented in a hurry due to tightening up security and safety around embedded images. I've brought it up to the devs to hopefully rectify, as if an instance is trustworthy enough to federate with (aka, not actively malicious) then it is probably safe to show their embeds (behind a blur).

At the latest, this restriction will go away when lemmy upgrades to pictrs 0.5 which will support proxying image requests, but unless there are objections from the rest of the team we will likely add all federated instances to the image allowlist before then.

I really hope we can restore the old Active algorithm, it's still on the table afaik, but I'm told the way that lemmy's database schema works has changed enough that it isn't trivial to switch back to.

HOW AM I JUST FINDING OUT WE OWN HEXBEAR.COM???? WHICH ONE OF YOUZE

yes! Movie night going on now at live.hexbear.net