I don't find this that interesting since the bug was not "fixed" in the sense most people probably think about fixing a bug -- i.e. someone picks it up, investigates it and writes a fix. It was closed due to housekeeping since, as the latest comment states:
> "legacy" extensions are gone
While I agree that housekeeping large backlogs is commendable, this bug was if anything fixed by "accident", and is no more a fix in the traditional sense than closing a bug for an EOL operating system because the issue described no longer exists.
Not really. The real feature being asked for was to prevent arbitrary extensions from accessing the filesystem. That specific request has been granted, as WebExtensions cannot access the filesystem.
The situation that no other "safe" method of accessing the filesystem was not even considered by the bug's author, but it does address the issue.
Closing issues after a while if the reporting user fails to follow up on a request for additional information can be useful. But more often than not these stalebots kick in because the maintainer(s) never chimed in. Don't use a bot that can't distinguish between those two cases unless your only aim is to wage war on your users and sweep everything inconvenient under the rug.
> WebExtensions have various permissions associated (though not controllable by the user -- merely declared and accepted or not
I think this is a major flaw in how permissions are implemented in Firefox (and Flatpak and other pieces of modern technology).
Software commonly "declares" what permissions it wants, but the user doesn't have to opt-in to grant these permission. They're granted by default, and there's usually no way to deny it.
I think iOS has a good approach here, where an application asks for camera permission and there's two buttons: Grant or Deny. The prompt also comes when camera access is actually required, not at software installation time.
"Well, the standard documentation (w3c) says there is "onload" event, then Firefox does not comply the SVG standard...because the performance is important....it is sounds good." Miguel
"I know what the standard says, that's why I set this bug to WONTFIX rather than INVALID" Robert Longson [:longsonr]
About 4 years ago I filed a bug report about tabs opened from a pinned tab not opening as the rightmost tab (it opens as the first tab). I also tried to write a patch for it, but the issue is still open.
Anyway, how is Mozilla to work for? I always thought it must be great, but recently reading about the firings and project cancellations it doesn't seem so rosy anymore.
Basically it wasn't a bug but a request to add some capability like security to extensions - useful for more powerful extensions like GreaseMonkey or in this case the one I was using Chickenfoot https://www.sitepoint.com/rewrite-web-chickenfoot/ which allowed you to do all sorts of things in scripts running inside an extension in the browser which might end up being dangerous. Basically extensions have changed a lot in those 15 years so not really surprising it was closed, just amusing that hey, that thing is still around I'd forgotten all about it!
I think the submission rules specifically frown upon editorializing titles. On the other hand the verbatim title would probably be meaningless to the HN crowd, which leads me to believe that your submission has no real discussion value.
This reminds me of a GCP issue that was opened in 2011 for users not being able to remove themselves from projects. It affects me still, I got an invite from a friend for a little hobby project he was working and he lost access to his Google and now I can't remove it from my GCP.
> That's a good idea. We can look into it, but I suspect that doing it
right will require either crippling Chickenfoot substantially, or doing
substantial rewiring of Firefox itself.
The direction Firefox decided to go was mostly "crippling substantially" of extensions, and not enough "rewiring of Firefox itself".
I opened bug #337051 in 2006 and it got closed in 2016. While I can't take any credit for the actual squashing of the bug it feels good having contributed to an important and very long-term project like Firefox.
Few months ago QA at my workplace found a bug with my work but I couldn't reproduce it. Turns out they're using Chrome and I'm using Firefox, and after reading some docs & specs, I concluded that Firefox's behavior is not correct. I'm about to file a bug and turns out that I found a same issue that's filed 20 years ago, and it's still open today: https://bugzilla.mozilla.org/show_bug.cgi?id=156090 Quite amusing...
Priority on fixing bugs is some combination of their severity, the number of users affected, and the difficulty/disruption involved in fixing it. The age is not relevant.
Not, it's been three days, lets use a bot to remove the bug or close what might be a very useful thread for others that get hit by it (and that can comment of a bug is still extant).
Though I could see the point in a "dormant" tag, or something that let's other users know that the dev is probably not thinking about the bug now.
And I appreciate that Mozilla is still going through them on occasion to see what is still relevant.
It's depressing when some maintainers launch a new version of their program, then immediately mass-close huge swathes of bugs with a "if it's still a problem, re-open a new ticket" kind of message. I mean, I get why this is done, bug databases are huge and and always growing, but as a user it is immensely frustrating and makes me less likely to report issues in the future.
In this case they closed the bug because a competing browser launched with the "bug fix" as one of its most touted features, and Mozilla spent several years rearchitecting Firefox in order to support the requested feature. This is a triumph.
That's not how I would describe it and not how it was described at that time. It was deemed necessary to discontinue legacy extensions to improve the browser.
Well, I could be wrong, but as I understand it, the particular way in which the browser was improved is that, now, browser and extension components can be sandboxed, which is what the bug was asking for?
Back in the 80's, I decided to include a bug list on the floppy disk that distributed my compiler. A magazine published a review of the compiler, and published the bug list as most of the review.
This is interesting, but since the request for enhancement that is the main link here was closed because it "worksforme" (i.e. it's fixed) I'm not sure why it's relevant information?
If anything the link is very solid evidence that Mozilla don't do that either since this issue remained open even after it got done.
Surely age is relevant though. If something is very old it's priority should increase as it's in danger of never being fixed in the lifetime of the product or being superseded when the feature is re-architected / removed.
Is the point of priority to fix that issue or to improve the product? If it’s the former, old bugs should increase in priority.
If globally improving the product is the goal, deprioritizing (or leaving alone) old issues is probably more reasonable. “We’ve lived with it for this long; how critical could it really be?” In this case, the risk of never being fixed is a feature, not a bug.
I have to admit that this is pretty much how I regularly close bugs (company-internal). In my case, I admit that there's a level of intentional sloppiness involved. The decision involves a combination of wanting to reduce my backlog to what's relevant, knowing about circumstances and how they have changed, particularly knowing that the area in question has been highly refactored, such that even if the bug technically still existed, its manifestation would be quite different, and the fact that it's been around so long without having bubbled up to the top earlier. Rarely does all hell break loose just because I have removed a bug from our collective memory by closing it prematurely. Also, often I follow the "much has changed" comment by something like: "feel free to reopen if I got it wrong", and people subscribed to the ticket could then respond (which they rarely do).
While I agree, before issues were called issues they were called bugtickets (regardless if it's actual defects waiting to be fixed or feature requests).
I agree that that should be changed, but dollars to donuts (as I have seen this happen many times before) the moderators rename it to the title of the bug and the entire point is lost ;P. (Though maybe they read this and think again; in the future to make such a point you first need to write a comprehensive article on your own blog with this as the title and then you mostly get to editorialize all you want... you just need to make sure it has enough heft to it to avoid anyone considering it "blog spam" and thereby changing the link in addition to the title ;P.)
Without the made-up title the point is lost but there really isn't much point left, in this case. Bug tracker post titles are an edge case the title rules don't deal with all that well, as you've recently commented yourself. But it's not a particularly important edge case by the expedient that most bug tracker posts (especially to live bugtrackers) are lousy HN posts to begin with.
I remember that the introduction of the new WebExtension API to replace the existing extension system was heavily criticized.
The old system gave extensions deep access to the browser and the new extension API (copied over from the Chrome browser) was seen as a limiting dumbing down.
It was a painful transition but very much needed. Now extensions don't clash with one another. The browser code can be modified more freely without impacting extensions and it is possible to implement features such as sandboxing.
My two most important extensions were my adblocker, and Vimium (enable Vim-like control in Firefox). The new WebExtension API broke Vimium, with no replacement possible[1]. Meanwhile, I never had problems with extension clashes.
I appreciate that this improved the code base quality for Mozilla folks, but it was a significant step down in features for me. I even switched to Vivaldi (which has built-in Vim keybindings) for a while because of this.
[1]: There are some partial replacements, but they all fail if you try commands on a still-loading page, and they don't work at all on any browser page like New Tab or Settings. So even a simple hotkey for "go to left tab", or "close current tab", fails constantly. I didn't stick around to find out what else is broken.
I know you might not be interested in anything chromium-based since this thread is about firefox, but qutebrowser[1] is a great solution for anybody looking for vimium/pentadactyl-like experience.
The only reason I switched away from Vivaldi was the sluggish UI (too many things on the main thread, I guess), but I hear there have been improvements in that area. I may give it another try.
There are workarounds for many of these things, to differing degrees. The genius of open source is that you can even fork the browser if your target audience is geeky enough, while not exposing your friends and family to malware in their standard browser.
Forking something as complex as a browser is doomed to fail unless you have a lot of money. Sooner rather than later you won't be able to port patches and shortly after your fork will be riddled with security issues and incompatibilities.
I feel your sentiment regarding Vimium - I was using Vimperator and it took quite a while to remap my fingers from gt to Ctrl-Tab while the page is loading.
But I really do love Tridactyl, even if only for the link hinting. I really suggest that you give it a few weeks. Remember, learning VIM took you longer than a few weeks.
I've been using Vimium since I use firefox (for around 3 years).
It's annoying that Vimium can no longer control the browser UI and is limited on some pages (New Tab, mozilla.org) but this is necessary for security.
Why? You can't read the source of this addon and evaluate whether or not it should have this access? This should be a permission that you can grant to an addon, we're not children that must at every juncture be managed so they don't burn their fingers.
Children are everywhere. They shouldn't drive cars, so we don't let them. If they shouldn't manage browser plugins, we shouldn't let them. This is really incredibly immaterial to the point - which is that browsers treat everyone like they have some sort of mental handicap.
In a competitive market, which browser is going to win, the one that says "no one under the age of 16 can use this browser because they're too likely to fall victim to the security holes we intentionally didn't fix" or the one that says "we fixed that security hole"?
I actually use a vim-style plugin in Firefox and this seems obvious to me, how do you think the majority of users feel?
But still, the inability to modify the UI is a major drawback.
I used to rely on TabMixPlus to have multiple rows of tabs even the ability to mouse-wheel scroll them so get access to more rows and other things like lock them with a MMB press.
I often have so many tabs open that now I'm not able to read the title and am forced to drag them off to create a new window in order to get a new row of tabs.
There was also an extension where I could split the main pane into multiple tiles in order to view multiple pages at the same time.
I'm not saying that it was a bad move to move to the new extension model, but I think that an API should exist which allows developers to modify the UI in a secure way.
Maybe vertical tabs would work for you? If you want something simple and fast, Tab Center Reborn is nice. If you want something more with more features, Tree Style Tabs is good enough but it is somewhat slow and and hard to configure.
Yes. It's a shame that the firefox user base is so easy to outrage. Same with the more recent change ragrding tabs. I am using firefox for a very long time now, and I just don't see that firefox is massively going downhill so far, like many people seem to suggest. Of course I am bummed out that certain features could not be retained (such as installable PWAs on desktop). But these are just the realities of the fact that it is hard to compete with google.
> Yes. It's a shame that the firefox user base is so easy to outrage.
Firefox's user base was a third of all internet users a little over 10 years ago. Now it's as little as 5%.
The "the users are wrong" attitude might not have been the main cause of the decline but it has been a real factor, IMO.
> Same with the more recent change ragrding tabs. I am using firefox for a very long time now, and I just don't see that firefox is massively going downhill so far, like many people seem to suggest. Of course I am bummed out that certain features could not be retained (such as installable PWAs on desktop). But these are just the realities of the fact that it is hard to compete with google.
In Firefox's heyday when they were a scrappy underdog they took on King Kong on its home turf (the Windows desktop) and won (or at least took a huge chunk of market share). The idea that what has now become a big rich company that makes nearly half a billion dollars a year from their browser somehow doesn't have the resources to make that browser competitive is hard to believe.
Firefox was quality wise on a higher level than IE 4, and it didn't loose any of that. IE got better over the years, made a massive step forward with Edge and now again with Chromium based Edge. And finally MS is approaching Firefox in terms of quality. What kind of funding does MS have, compared to Firefox? And still they are outsourcing the hardest part of browser development, while Mozilla is still doing it on their own, as a much smaller company. Chrome gained on Firefox, not because FF got worse. It did, because it is a real competitor, made by a company with an unfair competetive advantage (an even larger competetive advantage than MS has).
What about Opera? Did FF decline quality wise against that? Or Safari? No, of course not. FF didn't decline, it now has a real formidable competitor.
What exactly did they do that is most accurately described as listen to their users? Maybe I don't know everything that happened. But from my understand they made the best browser they could given the resources and succeeded massively, because the competition was so much worse at the time.
Also, they still make a competetive browser, as I laid out. Just the fact that some of the competition has improved massively (but by no means all of it) doesn't change that.
Provided useful features and functionality that people wanted. Tabs and plugins are a couple of big ones off the top of my head that people loved. It was also adopting open standards and new technologies though, which was an uphill battle because Microsoft was fighting them with incompatibilities and closed extensions, but people actually did like those things. Good support for developer features as far as I know went a long way to getting around that and having content providers take up and support firefox as well although I'm not a web developer so I'm a bit less sure of that aspect of it.
Competition has improved but so has firefox. Why should the expectation be that they stood still while everybody else went ahead? And it absolutely has declined. You also did say that they don't have features you want and seemed to imply that was part of the realities of not having enough resources or struggling to compete with google. Just doesn't seem like the reason holds water.
I think you misunderstood me. How did they decide what to implement? Reacting to the outrage of individuals from their user base? I don't think so. Instead they innovated and did what nobody really asked for, because they knew it was good and had the capabilities to do it.
I don't know how their process worked exactly but if you're going to just claim they didn't listen to their users and therefore you win the argument that's pretty cheap.
They certainly listened to their users and potential users.
It's not cheap. I gave reasons why the world changed. You reasons (they used to listen, now they don't) don't hold water, because you can't point to anything concrete.
> I remember that the introduction of the new WebExtension API to replace the existing extension system
Actually, the existing system is still alive and kicking, since the internal components of firefox, above a C++'ish core, are (more or less) like traditional extensions. It's just that you're not allowed to load your own anymore. In Thunderbird they've created a loophole of sorts, so we can still load normal extensions.
> It was a painful transition but very much needed.
On the contrary, it was the opposite of what was needed.
> Now extensions don't clash with one another.
1. Many important extensions simply aren't allowed to run now.
2. They don't interact, so in particular they don't clash.
> The browser code can be modified more freely without impacting extensions
1. It still impacts the internal extensions.
2. Since webextensions can do very little, they're not impacted by much.
We've never recovered from there. Addon functionality is strictly worse, and nothing that was gained is something I feel is a net positive in my life. It's nice that the engineers feel better, but as a user it was absolutely a bad choice that was never recovered from. Honestly, for folks creating a product this attitude is unacceptable.
I just found it amusing, I had forgotten all about this it was so long ago. I hope it doesn't turn into a pile-on on mozilla, who after all make my favorite browser.
I think if the title had been "A feature I requested 15 years ago got added 5 years ago and someone just noticed my similar issue and closed it", it would have inspired a very different conversation, and is probably a good example of why HN is such a stickler about titles.
Thought M$ was the worst. In VisualStudio 2008 they introduced a really annoying bug that in environments that had non-English IMEs installed, when there was a compilation error, the default IME would be invoked, and of course, when you tried to fix the error, what you typed would make nonsense to the compiler. Contacted M$, they promised thatit would be fixed in VS2008 SP1. But the fact was they never made it until some versions of VS2016. When it was fixed, those IMEs had been removed from my dev envs for ages.
> "legacy" extensions are gone
While I agree that housekeeping large backlogs is commendable, this bug was if anything fixed by "accident", and is no more a fix in the traditional sense than closing a bug for an EOL operating system because the issue described no longer exists.