Live data from Hacker News

17 year old Firefox feature request fixed

bugzilla.mozilla.org

271–280 of 281 posts

Re: 17 year old Firefox feature request fixed

#271
post #22

Earlier quoted context omitted.

Having a revenue stream helps.

Does it? It's not like you're paying GitHub per open issue. I've literally had issues I filed that the maintainer verified as an actual bug be closed due to lack of activity. I can understand that an unpaid maintainer doesn't have the time or motivation to fix it, but closing issues you know are valid seems insane to me.

The maintainer may see issues as "something that they should fix", vs "something that could be fixed". If they see it as the former and have no intention of working on it, then closing makes sense. I don't think there's a universal code of conduct on how to handle Github issues.

Re: 17 year old Firefox feature request fixed

#273

Earlier quoted context omitted.

It is possible to do both. The answer is customization, about:config already exists.

> I'm firmly in the anti-customisation camp myself. > It is possible to do both. The answer is customization Err well that’s not doing both then is it? That’s having customisation. I don’t want customisation. So that’s not doing both at all that’s just doing it your way and ignoring me.

Exactly ;-)

Re: 17 year old Firefox feature request fixed

#274
post #39

Earlier quoted context omitted.

Wait is Emacs lying about its age again?

Emacs was released in 1985. That's 36 years ago. Half of that is 18. What am I missing?

Apparently, the downvote restriction to wise users doesn't prevent some of them from being trigger happy. Maybe the release date stated above is wrong but I'm shocked to see this kind of comment downvoted.

Re: 17 year old Firefox feature request fixed

#275

Earlier quoted context omitted.

The counterargument is that a bug is enough a function of its context that the older they get, the less likely they are to still be relevant or accurately documented. Having a bug on the list isn't enough - it needs to be periodically reviewed, kept up to date, prioritized, etc. Sometimes the overhead of that maintenance work isn't worth it, particularly for a bug that's been explicitly categorized as 'low priority'…

I think it's actually a problem with issue trackers, which have only this binary open/closed status, where the only way to express "outdated" is with a label or something. As a project maintainer, I don't want to close unfixed issues because they become much harder to find (hidden by default), which results in duplicate reports if it turns out the issue is not fixed. Also it can be rude, if it was a high effort bug r…

with Jira workflow, it's kinda possible to do that, with a status like backlog, so the bug is open, but can easily be filtered out

Re: 17 year old Firefox feature request fixed

#276
post #225

Earlier quoted context omitted.

Because not many people use it. I don't think many people have the desire to save a whole web page. For other unseen you can probably just get away with taking a screenshot, sending the tab / sharing the link, or using an archiving site to save it for later.

"Because not many people use it" was the excuse Google gave for killing RSS.

RSS is dead?

* check own RSS feeds *

Nope, still alive

Re: 17 year old Firefox feature request fixed

#277
post #155

Earlier quoted context omitted.

I'm not totally following what you're saying, but I can answer this: > Is a wontfix with lots of comments more expensive, than a wontfix with comments blocked? Yes, it is more expensive. When 100 developers are CC'd on a bug that is generating regular "but did you consider this argument?" comments, it's a lot of overhead. You could argue that everyone CC'd should remove themselves from the CC list when this happens,…

> These bugs are not fun for anybody, dev or unhappy user alike. Then fix them.

This isn’t a bug though. It’s a feature request where the devs have already vocally said no. This idea that opening an issue for a feature somehow implies that it will eventually get implemented seems so wild.

If I opened an issue asking Firefox to switch their rendering engine to Blink you better bet it would be closed wontfix and stay that way for a long ass time.

Re: 17 year old Firefox feature request fixed

#279
post #190

Earlier quoted context omitted.

The downside is that Mozilla tracks thousands of open tickets, most of which are probably obsolete. But who is going to start now with reviewing stuff from 20 years ago? As much as it pains me (I’m still tracking multiple bugs I reported) to say this, but all tickets with no activity for some reasonable time period must simply be closed. Things are _already_ out of control.

That's too simplistic. What if it IS an issue, or what if it WILL be fixed, but because of priorities it's always bumped down the list? What do you then, bump it every few weeks? No, any open source project needs someone (or multiple people) triaging tickets; either keep them open and make sure they are implemented in a reasonable time, or close them as a 'wontfix'. Of course, then you'll have the issue of people ope…

I think there is a place for "Priority: Would Accept Patch". AKA we don't think it is a bad idea (otherwise we would close) but at this point we don't think that "the developers" will ever get to it. However leave it open, people can mark interest (hopefully with a vote not a bump) or maybe even write a patch. It's not hurting anyone just sitting there.

Re: 17 year old Firefox feature request fixed

#280

Earlier quoted context omitted.

I just laughed when I saw your comment, and the bugzilla links are styled as "visted" (i.e. gray instead of black.) I hate that behavior. When I click in the address bar, it's because I want to edit the URL. If I want to go somewhere else, I'll open a new tab, or use a bookmark, or click a link on a page. In the rare case that I want to type a whole new URL, but keep the same tab, I can easily triple-click or [Cmd]+A…

When I click on the URL bar I often want to edit it too. But it's difficult to click the leftmost or rightmost character to position the cursor. So after clicking, I usually tap Ctrl+A (Cmd+A) to "select all" anyway, and then tap left-arrow or right-arrow to deselect and jump to the chosen end of the URL. Cursor keys only junp to the end if it's selected. My keyboard doesn't have dedicated home/end keys, but I'd prob…

Just use the Home or End keys.
Post reply on HN