Firefox doesn’t implement the AudioData API, which is probably necessary for the waveform viewer and cropping tool Discord presents in the soundboard management UI.
Not everything is about Chrome DRM yall.
Yet another experimental API only supported by Chrome. Chrome has always been like this, implementing experimental API that hasn’t been finalized yet. You might say they’re innovating to support new technologies, but actually it’s more like they’re doing whatever they pleased, as demonstrated by their removal of jpeg xl support despite web communities plea not to do so (a new more efficient image compression, but not made by Google so screw it), pushing manifest V3 and ad topics, and recent push for web environment integrity API.
I think Moz helped write and supports this. I even think it’s (partially enabled in nightly?)
Not sure if these built in decoders are supported though. Seems a bit dangerous to expose native codecs directly from the web to be honest, since you’ll end up with wildly varying support across browsers.
I remember ages ago websites were all focused on “works best on Internet Explorer” or “please use Netscape for the best experience”
We managed a good solid decade after that where browsers all somewhat caught up to each other and now we’re going back that way again, with each website just YOLO implementing APIs that aren’t fully supported (with no polyfils or fallbacks)
When you did that back in IE7/8/9, you missed out on rounded corners or drop shadows, now whole parts of apps won’t work unless you’re on chrome 🤯
Thank fucking people like you. The average Lemmy user just knows everything.
I have seen so many Lemmy users think they are better than Reddit users. Truth is, you are all fucking ass holes you are just different kinds of ass holes.
None of us agree with Google’s choices but for fucks sake not everything is because Google chose it.
Sometimes it’s just in the damn browser. Like fuck off.
I use Chrome and Firefox and have two different online personas with both.
It appears the Reddit users that don’t read further than the title have arrived on Lemmy.
Because Firefox is like a democracy, they prioritize work based on number of votes on issues/feature requests. The AudioEncoder API has literally just one vote, and the overall WebCodecs API that it’s a part of only has five votes. This shows that there’s very little demand for it, meaning very few sites actually use this (that or the vast majority of Firefox users don’t use/need this feature). Why bother focusing your efforts on implementing something that most users don’t care about? The higher priority things that most Firefox users care about is stuff like performance, and Mozilla have been making some good progress too on that front.
The thing isn’t only about votes. Both APIs are top priority but there are blocked and depends on other stuff that also needs to be fixed or implemented.
This is an experimental API that hasn’t been finalized yet. Firefox devs has limited engineering resource and simply can’t keep up with Chrome’s push to implement experimental/proposal API. Safari also hasn’t implemented this yet because they also usually wait until the API finalized, which can take quite a while.
Hope you’ll continue to lick the Google even after Chrome implements DRM.
And their desktop client technically is a browser without omnibar.
Electron is not just a browser. It’s more like a native app framework that just happens to use HTML and CSS to render UIs. You can do anything the OS lets you do, not just what a browser environment would let you do.
Electron is an unholy fusion of Chromium and Node.JS. Nothing more, nothing less. It doesn’t ‘just happen’ to use HTML and CSS. It’s literally just a browser with most of the default browser UI being hidden. Something like React Native would better fit your definition.
I’m on my lunch break from working on a React Native codebase, and I wouldn’t say RN fits that definition at all… but I think we’re just getting lost in semantics.
My point was just that a web app running inside a browser has to abide by the rules and limitations set by the browser, whereas Electron flips that relationship – your app sets the rules and limitations of what can be done, and the web rendering process abides by whatever environment you create. You can do anything the OS permits. Even from inside a web context, if you want. You don’t need a browser-managed sandbox to mediate your interactions with the OS.
It’s not literally just a browser. It’s literally just a web engine with a full set of OS calls hooked in. It is not a browser in the same way GNOME is not an OS. A browser comes with a whole lot more than a web engine, so calling it “a browser” is wrong both technically and colloquially.
But probably Chromium right? They probably didn’t make all Discord functions work for Firefox as that would require some extra work probably.
I’m a little baffled by this one. File upload isn’t exactly some new HTML5.1 feature or anything. There’s no good reason they can’t have this handled properly.
I ditched Discord a few weeks ago. I moved to Matrix!
Not to be discouraging, but i managed to quit discord for a few months, but i returned again, turns out many projects, even open source, use discord for discussion only
The Lemmy of chat apps but not there yet for video/screen share for multi person rooms
There’s really no reason to be mad at them in this particular instance. Their client is Chromium-based (Electron) so they will optimize their new features for that engine first. There’s probably less than 5% users who Discord from browser, let alone Firefox, and I think I’m being generous with that number. Additionally, some things are harder to implement (or even impossible) in native web rather than Electron, that has all the NodeJS integrations.
File upload is not a chromium feature, it’s a super old basic feature. It’s just their pittiness and upcoming drm implications. I bet if you set your user-agent to chrome it woould work just fine.
Firefox doesn’t implement the AudioData API, which is probably necessary for the waveform viewer and cropping tool Discord presents in the soundboard management UI.
Not everything is about Chrome DRM yall.
Edited to add screenshot of spoofing user-agent on Firefox and getting an error:
https://midwest.social/pictrs/image/4edb0d24-0c2a-4610-b7b2-eed07a3c7d24.png
Here’s what happens when you spoof a Chrome user-agent.
https://midwest.social/pictrs/image/d3b96401-956b-4eab-bc5c-64b0743feae4.png
-kibiz0r@midwest.social
This dialog doesn’t do just file upload, after you upload you can cut the sound file into a 4-second clip, inside the client. My bet is that it might technically be possible to do it in Firefox, but not with the same exact code as with chromium, and thus they decided they don’t care.
You’re probably right. A modern browser that supports webassembly can do literally anything, implementing the missing AudioData functionality should be possible with enough development effort, but it’s not important enough for them to make this particular feature works on Firefox.
I haven’t used soundboard yet, but I’m pretty sure it isn’t “just” an HTML5 file upload. Perhaps it’s as you said, they run checks on the file being uploaded. Maybe it will work, maybe it will crash in some use cases because they don’t have a polyfill for some specific API they use. So instead of dealing with user complaints about crashes they just disabled the feature.
I’m also not sure why you’re upset with Discord for implementing DRM for uploaded files. If they don’t, they will get sued by the companies enforcing that DRM, so hate on those companies instead.
