Figured that much. I’m not a web developer, but I can read a profiler, and the CPU usage spikes before those gaps are a pretty good sign that this isn’t a memory leak. I use uBlock Origin, by the way, but there’s likely some weird interaction between it, other Youtube extensions and Youtube’s own attempts to nuke adblockers from orbit. And no, it’s not a cryptominer as far as I can tell. This looks like either a bug or an unintended behavior of the very popular, very sanctioned plugins running on Firefox (or Firefox itself).
Which is why, as I said, I have settled for periodic reboots. Convenience wins over principle often, but I happen to be stubborn.
Gotta say, though, I appreciate the attempts at troubleshooting, but the OSS and privacy communities in general have a tendency to respond to comments on poor performance, compatibility or UX with tech support, and I think it’s kinda missing the point.
The unfortunate thing is, most people aren’t having these kinds of performance issues. If a bug can’t be reproduced, it can’t be fixed. That makes these kinds of things pretty much impossible to fix until someone who is having the problem has the time/energy to dig into it, and the technical expertise to know what information and data to provide for a good bug report (which, honestly, is very rare), and then make themselves available for all of the inevitable follow-up questions and troubleshooting steps.
OSS devs are volunteers 99.9% of the time and they work on whatever they want to work on. A well written bug report with lots of context, a full memory snapshot, clear reproduction steps, expected/actual behaviour, full information on how to set up the environment from a fresh install, and so on, has a really good chance of being picked up by a developer. But if it’s even a little bit harder to just get to work on it, it’ll probably be ignored, because there are a hundred other more interesting issues to work on.
People can only help as much as they’re able to, we can’t fix your issue unless we know what it is, and usually the best place to start is by trying to make sure the surrounding environment is sane. If we went off assuming there was a Firefox bug and spent hours looking at a memory dump only to discover that your computer is a 2003 Intel Celeron or something, it would be a bit frustrating.
And yeah, most people just do not have the technical expertise to write a good bug report for a web browser - most devs are web developers or do business logic stuff - so it’s a tough nut to crack, and there’s not a huge number of people volunteering to help out open source software teams doing the soft skills stuff to coax useful information out of people who report issues :)
Hope that makes sense! OSS is very much a “be the change you want to see in the world” kind of place!
Well, yeah, which would make perfect sense if a) Firefox was made by volunteers instead of whatever weird blend of non-profit and for-profit companies are running Mozilla these days, and b) if I was filing a bug report instead of casually mentioning that Firefox can be buggy sometimes in social media.
If I was filing a bug report I’d be attaching… you know, logs. And repro steps. As you do in a bug report. I don’t even know if Firefox has a bug submission process for the public. I assume they don’t. Most of those are worthless anyway.
Look, besides the notion that the whole discussion is rather pointless, the idea I was trying to impress earlier is that the end user doesn’t care or need to care about the challenges of OSS development. Being free and open source may be a practical selling point, a moral selling point or not a selling point at all, but ultimately when you use a thing you just kinda need it to work first. When you complain, or even just mention, an issue with some piece of OSS in places like this you just tend to get a bunch of IT and workarounds back.
Which is fine, I get it, it’s people trying to be nice, but… you know, it doesn’t make a great case for the ecosystem. Me saying “eeeh, FF can be a bit flaky sometimes you may want to reboot it every now and then” is an anecdote. Me saying that and going down a rabbit hole of profiling and memory snapshots in the futile attempt to fix some arcane interaction between Youtube and a bunch of add-on software Youtube doesn’t want me to run is rightfully enough to put off the average person. All I’m saying is not every person mentioning a thing they noticed in a piece of OSS needs a howto doc and a list of highly technical homework as a response.
I guess I don’t really understand - can you help me understand your viewpoint? What do you think a good response would be? Just like, “oh yeah, that sucks dude?” Sorry if I made it feel like I was expecting you to do technical tasks, it was just an offer of help to get it fixed, but obviously if you’d rather not do that, you’re not compelled! Just trying to help really. I don’t know what the better response would be - I’m autistic so sometimes I miss social cues so sorry if that’s the case!
The point was a simple observation that the OSS community tends to confuse feedback for requests of technical support.
It’s not you in particular and it’s not mean spirited or wrong to do. It is, however, a relevant note on why some OSS struggles with reach.
My go-to example of this is that nobody cares that Blender is open source, but people tend to flag it for GIMP. Because Blender “just works” and has comparable UX and features to paid alternatives. I know what’s on GIMP or Krita and my comment isn’t a call for help, just an observation.
In this case… well, yeah, it sucks that Firefox has a long-standing performance bug. If it gets fixed in the future it’ll be fine. If it doesn’t I’ll survive, but it may put off some people from joining if the effective experience is less responsive than Chrome’s despite what benchmarks may say.
Thanks for the extra information, but I still think I’m missing something - what’s the reason behind providing feedback if you don’t want them to do anything about the feedback? Like, you’re just making conversation about it, like sharing funny bugs you had in Skyrim?
I guess there’s a difference between talking about bugs and UX, because if you said that you prefer Photoshop to GIMP because you think Photoshop’s UX is better, I totally understand that, and “tech support” isn’t really appropriate, but isn’t that different for people who are talking about their specific performance issues? Like, how would you want people to respond to that?
it may put off some people from joining if the effective experience is less responsive than Chrome
Isn’t that a reason for people to be more helpful in helping others resolve their performance issues and to raise bug reports as appropriate? I really feel like you’re trying to have your cake and eat it too, here - it feels like you want Firefox to fix performance issues, but you feel like the issues should be fixed without actually giving devs the information they need to fix them. That’s just not going to happen for any app/software, OSS or not
Isn’t that a reason for people to be more helpful in helping others resolve their performance issues and to raise bug reports as appropriate?
No, see, that’s my point. There’s a whole family of bugs where people don’t want to be told how to fix the bug themselves, they want the bug to never have happened in the first place. Or, you know, at best for it to be patched and removed without their intervention.
Showstopper bugs? Sure, those you just want a way to get past so you can do what you want to do, but experiential bugs, bugs that don’t block you but make things slightly more annoying? For most people any additional effort in fixing the bug just makes the bug worse at that point. Especially if it’s not an open-and-closed “just do this and it fixes it”.
A slight performance degradation over time that clears up with a reset is not that big of a deal. Being walked through debugging processes I’ve already tried that won’t actually fix the issue is an extra annoyance on top of having to deal with the bug. At best. At worst it feels patronizing, in that hey, I know what I’m doing, right? It’s annoying in the way calling customer support and having to go through the dumb easy part of the script where they tell you to turn the thing off and on again is annoying. Except I didn’t call customer service, I just complained about the bug and now people on the Internet are crawling out of their hideouts to do customer service at me.
So no, no every situation calls for trying to walk somebody mentioning a bug through basic QA processes. Software is supposed to just work, and for the average user, if you add homework on top of their software not working, that’s just extra incentive to not use the software. OSS fans sometimes miss that small but relevant part of the user experience.
Maybe it would be easier to reframe the conversation.
Imagine that you live in a city that has a garage that gives away free cars. Most people get one and it works perfectly fine, but sometimes people modify them and it causes issues with the engine, nothing major but it’s a minor inconvenience. Maybe turning the car off and on again resolves it.
When said people have issues and talk about it, people ask them questions like “what changes did you make?” and “what kind of issues are you having?” with the idea of trying to help them, and maybe they’d suggest things like “try checking the on board diagnostics” or “check the spark gap” to try and help.
Don’t you see how saying, “I just expect it to work without having to do any homework or spending any time trying to fix it. I’m not a mechanic.” is kind of absurd in that situation?
It’s totally unreasonable to expect extremely complex software to always just work with zero bugs, even if you pay $$$$ for it. People can expect it to “just work” all they want - and for Firefox, it does. If you’re adding third party addons that break it, then you don’t have a Firefox problem, you’ve got an addon problem.
If you don’t want help, you don’t need to post about it. Being honest, you just seem pretty entitled to me, and I’m not trying to insult you, I just genuinely don’t understand what you expect with regards to your own situation. You say that you’re happy with the workaround you have but also that you think it should be fixed and you think it’s a problem with the OSS community that someone tried to help you to get it fixed? I just do not get it.
I’m actively saying that when most people hear a little noise under the hood they do one of two things: ignore it or take the car to a mechanic and use a different transport method for a bit until it’s fixed.
I’m saying that if somebody casually mentions “my car does a little noise” over the watercooler and the other person goes “hey, have you popped the hood and checked the spark gap” or “can you pull up the on board diagnostics and maybe we can go over them now?” the usual reaction is to make up some excuse or get glassy eyed and move on with your day.
That is absolutely how that goes.
And no, it’s not optimal or even particularly reasonable, but that’s the thing, it doesn’t have to be. When the average person engages with a market product for fun or casual usage they are often willing to invest zero effort in improving it from the out of the box experience, at least early on. And that’s their prerogative. That low barrier to attrition is a key element of UX design, and it absolutely applies to technical issues.
Figured that much. I’m not a web developer, but I can read a profiler, and the CPU usage spikes before those gaps are a pretty good sign that this isn’t a memory leak. I use uBlock Origin, by the way, but there’s likely some weird interaction between it, other Youtube extensions and Youtube’s own attempts to nuke adblockers from orbit. And no, it’s not a cryptominer as far as I can tell. This looks like either a bug or an unintended behavior of the very popular, very sanctioned plugins running on Firefox (or Firefox itself).
Which is why, as I said, I have settled for periodic reboots. Convenience wins over principle often, but I happen to be stubborn.
Gotta say, though, I appreciate the attempts at troubleshooting, but the OSS and privacy communities in general have a tendency to respond to comments on poor performance, compatibility or UX with tech support, and I think it’s kinda missing the point.
The unfortunate thing is, most people aren’t having these kinds of performance issues. If a bug can’t be reproduced, it can’t be fixed. That makes these kinds of things pretty much impossible to fix until someone who is having the problem has the time/energy to dig into it, and the technical expertise to know what information and data to provide for a good bug report (which, honestly, is very rare), and then make themselves available for all of the inevitable follow-up questions and troubleshooting steps.
OSS devs are volunteers 99.9% of the time and they work on whatever they want to work on. A well written bug report with lots of context, a full memory snapshot, clear reproduction steps, expected/actual behaviour, full information on how to set up the environment from a fresh install, and so on, has a really good chance of being picked up by a developer. But if it’s even a little bit harder to just get to work on it, it’ll probably be ignored, because there are a hundred other more interesting issues to work on.
People can only help as much as they’re able to, we can’t fix your issue unless we know what it is, and usually the best place to start is by trying to make sure the surrounding environment is sane. If we went off assuming there was a Firefox bug and spent hours looking at a memory dump only to discover that your computer is a 2003 Intel Celeron or something, it would be a bit frustrating.
And yeah, most people just do not have the technical expertise to write a good bug report for a web browser - most devs are web developers or do business logic stuff - so it’s a tough nut to crack, and there’s not a huge number of people volunteering to help out open source software teams doing the soft skills stuff to coax useful information out of people who report issues :)
Hope that makes sense! OSS is very much a “be the change you want to see in the world” kind of place!
Well, yeah, which would make perfect sense if a) Firefox was made by volunteers instead of whatever weird blend of non-profit and for-profit companies are running Mozilla these days, and b) if I was filing a bug report instead of casually mentioning that Firefox can be buggy sometimes in social media.
If I was filing a bug report I’d be attaching… you know, logs. And repro steps. As you do in a bug report. I don’t even know if Firefox has a bug submission process for the public. I assume they don’t. Most of those are worthless anyway.
Look, besides the notion that the whole discussion is rather pointless, the idea I was trying to impress earlier is that the end user doesn’t care or need to care about the challenges of OSS development. Being free and open source may be a practical selling point, a moral selling point or not a selling point at all, but ultimately when you use a thing you just kinda need it to work first. When you complain, or even just mention, an issue with some piece of OSS in places like this you just tend to get a bunch of IT and workarounds back.
Which is fine, I get it, it’s people trying to be nice, but… you know, it doesn’t make a great case for the ecosystem. Me saying “eeeh, FF can be a bit flaky sometimes you may want to reboot it every now and then” is an anecdote. Me saying that and going down a rabbit hole of profiling and memory snapshots in the futile attempt to fix some arcane interaction between Youtube and a bunch of add-on software Youtube doesn’t want me to run is rightfully enough to put off the average person. All I’m saying is not every person mentioning a thing they noticed in a piece of OSS needs a howto doc and a list of highly technical homework as a response.
I guess I don’t really understand - can you help me understand your viewpoint? What do you think a good response would be? Just like, “oh yeah, that sucks dude?” Sorry if I made it feel like I was expecting you to do technical tasks, it was just an offer of help to get it fixed, but obviously if you’d rather not do that, you’re not compelled! Just trying to help really. I don’t know what the better response would be - I’m autistic so sometimes I miss social cues so sorry if that’s the case!
The point was a simple observation that the OSS community tends to confuse feedback for requests of technical support.
It’s not you in particular and it’s not mean spirited or wrong to do. It is, however, a relevant note on why some OSS struggles with reach.
My go-to example of this is that nobody cares that Blender is open source, but people tend to flag it for GIMP. Because Blender “just works” and has comparable UX and features to paid alternatives. I know what’s on GIMP or Krita and my comment isn’t a call for help, just an observation.
In this case… well, yeah, it sucks that Firefox has a long-standing performance bug. If it gets fixed in the future it’ll be fine. If it doesn’t I’ll survive, but it may put off some people from joining if the effective experience is less responsive than Chrome’s despite what benchmarks may say.
Thanks for the extra information, but I still think I’m missing something - what’s the reason behind providing feedback if you don’t want them to do anything about the feedback? Like, you’re just making conversation about it, like sharing funny bugs you had in Skyrim?
I guess there’s a difference between talking about bugs and UX, because if you said that you prefer Photoshop to GIMP because you think Photoshop’s UX is better, I totally understand that, and “tech support” isn’t really appropriate, but isn’t that different for people who are talking about their specific performance issues? Like, how would you want people to respond to that?
Isn’t that a reason for people to be more helpful in helping others resolve their performance issues and to raise bug reports as appropriate? I really feel like you’re trying to have your cake and eat it too, here - it feels like you want Firefox to fix performance issues, but you feel like the issues should be fixed without actually giving devs the information they need to fix them. That’s just not going to happen for any app/software, OSS or not
No, see, that’s my point. There’s a whole family of bugs where people don’t want to be told how to fix the bug themselves, they want the bug to never have happened in the first place. Or, you know, at best for it to be patched and removed without their intervention.
Showstopper bugs? Sure, those you just want a way to get past so you can do what you want to do, but experiential bugs, bugs that don’t block you but make things slightly more annoying? For most people any additional effort in fixing the bug just makes the bug worse at that point. Especially if it’s not an open-and-closed “just do this and it fixes it”.
A slight performance degradation over time that clears up with a reset is not that big of a deal. Being walked through debugging processes I’ve already tried that won’t actually fix the issue is an extra annoyance on top of having to deal with the bug. At best. At worst it feels patronizing, in that hey, I know what I’m doing, right? It’s annoying in the way calling customer support and having to go through the dumb easy part of the script where they tell you to turn the thing off and on again is annoying. Except I didn’t call customer service, I just complained about the bug and now people on the Internet are crawling out of their hideouts to do customer service at me.
So no, no every situation calls for trying to walk somebody mentioning a bug through basic QA processes. Software is supposed to just work, and for the average user, if you add homework on top of their software not working, that’s just extra incentive to not use the software. OSS fans sometimes miss that small but relevant part of the user experience.
Maybe it would be easier to reframe the conversation.
Imagine that you live in a city that has a garage that gives away free cars. Most people get one and it works perfectly fine, but sometimes people modify them and it causes issues with the engine, nothing major but it’s a minor inconvenience. Maybe turning the car off and on again resolves it.
When said people have issues and talk about it, people ask them questions like “what changes did you make?” and “what kind of issues are you having?” with the idea of trying to help them, and maybe they’d suggest things like “try checking the on board diagnostics” or “check the spark gap” to try and help.
Don’t you see how saying, “I just expect it to work without having to do any homework or spending any time trying to fix it. I’m not a mechanic.” is kind of absurd in that situation?
It’s totally unreasonable to expect extremely complex software to always just work with zero bugs, even if you pay $$$$ for it. People can expect it to “just work” all they want - and for Firefox, it does. If you’re adding third party addons that break it, then you don’t have a Firefox problem, you’ve got an addon problem.
If you don’t want help, you don’t need to post about it. Being honest, you just seem pretty entitled to me, and I’m not trying to insult you, I just genuinely don’t understand what you expect with regards to your own situation. You say that you’re happy with the workaround you have but also that you think it should be fixed and you think it’s a problem with the OSS community that someone tried to help you to get it fixed? I just do not get it.
Yeah, no, I’m actively saying just that.
I’m actively saying that when most people hear a little noise under the hood they do one of two things: ignore it or take the car to a mechanic and use a different transport method for a bit until it’s fixed.
I’m saying that if somebody casually mentions “my car does a little noise” over the watercooler and the other person goes “hey, have you popped the hood and checked the spark gap” or “can you pull up the on board diagnostics and maybe we can go over them now?” the usual reaction is to make up some excuse or get glassy eyed and move on with your day.
That is absolutely how that goes.
And no, it’s not optimal or even particularly reasonable, but that’s the thing, it doesn’t have to be. When the average person engages with a market product for fun or casual usage they are often willing to invest zero effort in improving it from the out of the box experience, at least early on. And that’s their prerogative. That low barrier to attrition is a key element of UX design, and it absolutely applies to technical issues.