Live data from Hacker News

17 year old Firefox feature request fixed

bugzilla.mozilla.org

241–250 of 281 posts

Re: 17 year old Firefox feature request fixed

#241

Earlier quoted context omitted.

I was using Emacs in 1982, and it had been around for several years before that.

I love it when old-timers weigh in on HN comments. What do you use these days?

not OP, but Emacs ofc [1]

[1] why on earth would they go through the traumatic change of reprogramming their muscle memory after so many years? it would be like a wizard that voluntarily gives their power away. like a father sacrificing his own child.

Re: 17 year old Firefox feature request fixed

#242
post #186

Good on them for actually tracking this feature request for over a decade and not just closing it after three weeks for “lack of interest.” Looking at you, every random GitHub project ever.

Absolutely. I severely dislike the "bug scrub" attitude that's prevalent in some places that amounts to just closing anything that is not P1 and older than some short time window. The idea of a bug tracker is to track bugs in the product. If the bug still exists in the code, the bug in the tracker should still be open.

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' for years. The fact that a bug can stay at low priority for years is a reasonable sign that it's not too important to spend a lot of effort either tracking it or fixing it.

With that point of view, closing the defect as unfixed and explaining the reasons why is in some ways more honest than just keeping the thing open ad infinitum just because somebody, at some point in the past, thought there was an issue. And if closing it was wrong, you'll run into the issue again, and can either re-open the defect or submit a new defect with a back link to the original, and an explanation of what's changed that's brought it back into relevance.

(Personally speaking in the last few months, I've gotten several good solutions from reading the commentary on defects that were closed as unfixed.)

Re: 17 year old Firefox feature request fixed

#243
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.

Google Reader ≠ RSS.

Re: 17 year old Firefox feature request fixed

#244
post #217
post #186

Earlier quoted context omitted.

Absolutely. I severely dislike the "bug scrub" attitude that's prevalent in some places that amounts to just closing anything that is not P1 and older than some short time window. The idea of a bug tracker is to track bugs in the product. If the bug still exists in the code, the bug in the tracker should still be open.

I'm one of the maintainers / developers / support personnel for an internal app that was created circa 1996. We still have open bugs that's 20 years old and haven't yet been fixed. When I got this role, I instated a culture of never closing old bugs, despite some of my managers wanting me to do that many times, and one of them even going on a rampage once and closing some of them (which I reversed as soon as he left)…

Open bugs are also history - and amazing for support; a "known bug" will have workarounds or suggestions on how to avoid hitting it, even if it never gets fixed.

Closing bugs just to make dashboards/metrics look better is wrong; either adjust the dashboard or fix the bugs.

Re: 17 year old Firefox feature request fixed

#245
Nit-picking here, but language is important.

Not sure I like the idea that a "feature request" can be "fixed". It's a feature, not a bug. It's a request, not some sort of obligation of the development team.

Still though, it's good to see a process work over a 17 year long period, in an industry where things oftentimes seem to be thrown out in a matter of a few years.

Re: 17 year old Firefox feature request fixed

#246
post #30

Earlier quoted context omitted.

To think I was still using Eclipse a scant 7 years ago...

I started off with Eclipse in school, I still stash all of my code in a folder called 'workspace' as a result. But, I've since switched to intellij for Java (and later, lightweight editors like Sublime Text for JS, until a while later JS finally got modules and editors added more support for JS), and nowadays I'm using it for everything; I'm currently managing a 200KLOC application (it's too much but my employer isn'…

Ack...that's some old PHP

Re: 17 year old Firefox feature request fixed

#247
post #67

Earlier quoted context omitted.

That's interesting. In my case, I hardly edit urls manually in the address bar. Usually I end up on a site either by clicking on links or copying and pasting a whole url from elsewhere. So, when I click on the address bar it's almost always to copy that url. Exception may be if you are front end dev testing different paths on the browser in which case editing in the address bar could be common.

But the automatic single-click selection doesn't fill the X clipboard (meaning it isn't pasted by middle click), so when I want to copy it I have to triple click anyway. Since it looks like it's selected, I frequently forget to do so, which results in pasting something I didn't mean to.

I single-click in address bar, which selects all (in Chrome), then I command-c shortcut to copy.

Which is my main use case for clicking in the location bar, copying the URL. So I appreciate that single-click selects all, so I can then copy with a keyboard shortcut.

I'm confused by your comment "when I want to copy it I have to triple-click anyway" -- I'm guessing you are on linux(?)... does triple-click or select alone automatically copy on Linux? (If select alone normally copies to clipboard, then I'd say it's a bug that it "looks selected" but hasn't copied to clipboard?)

This may be a thing where different behavior is appropriate for different OSes. Perhaps the FF devs who rejected the feature are also Linux users? I think FF wants to get market share beyond what can be achieved focusing on Linux users though.

Re: 17 year old Firefox feature request fixed

#248

Earlier quoted context omitted.

I was using Emacs in 1982, and it had been around for several years before that.

I love it when old-timers weigh in on HN comments. What do you use these days?

Emacs of course ;)

Gosh, "old timer" :(

Re: 17 year old Firefox feature request fixed

#249

Earlier quoted context omitted.

I was using Emacs in 1982, and it had been around for several years before that.

I love it when old-timers weigh in on HN comments. What do you use these days?

Started with Gosmacs. Working in the CMU graduate terminal room with the man himself. I was just a freshman undergraduate, but a graduating student gifted a coveted X1 key to me. Mostly coveted due to the coke machine.

https://www.cs.cmu.edu/~coke/history_long.txt

Re: 17 year old Firefox feature request fixed

#250

Earlier quoted context omitted.

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

I think GNU Emacs was released in 1985, but Emacs existed before that. Similar to vim and vi relationship. In fact, Emacs was first implemented as a plugin (a set of macros in the language of the time) for a now forgotten editor called Teco, which was one of the first, if not the first, programmable editor ever.

That's the "macs" in Emacs: Editing MACroS.
Post reply on HN