Off topic but I really dislike the trend of using “human readable durations” like “a month ago”, just tell me the bloody date, I can figure out for myself.
Outlook (Mac version at least) is the worst offender. For emails prior to the current day it will say for example just “yesterday” and it will only show you the time if you click on the email. I get dozens of mails per day, having just “yesterday” for 50 messages in a row is useless.
Ha! I was subscribed to this bug for most of those 25 years. Note that Firefox didn't exist at the time, this was filed against Netscape Navigator.
Don't remember why I was subscribed to the bug, must have commented on it or something. Got the occasional email notification about it over the years, always got a chuckle out of it. Then a couple of days ago, lo and behold, it was fixed!
I find it amazing that your subscription to that bug thread survived all those years. Wow!
I have a few bugs that are almost ready to go off to college, and I get an email about once a year from various machinations involving them.
And then you have stale bot on GitHub closing issues for no activity in like 3 months -_-
Closing is one thing—at least you can still use the issue as a communal gathering point to make slow progress. The casual locking on the other hand is mystifying.
And so often there’s the added gaslighting of a project that provides some rationale for closing but then inexplicably locks too as if that’s the same.
Closing is great - it’s an honest assessment that “we’re not going to work on it.”
It still turns up in search and you can comment on it (some even reopen automatically if you do).
Locking automatically is just the worst - we don’t care, we won’t care, and you’ll never get us to care.
I like these kinds of statements, they let you know right off the bat that your time is better spent elsewhere. People who see this as normal will screw you over sooner or later in other ways, e.g. by changing licenses or needless rewriting over and over and over again. At least that's been my experience.
That bot is disgusting. I spent a lot of time and effort to write detailed bug reports only to have this stupid bot spit in my face close them (and yes, some of the bugs are still there till this day).
I've learned not to bother submitting bug reports unless I can guarantee that my time will not be wasted. If I find a bug in a project that doesn t guarantee this, I either fix it privately for myself or switch to another project.
Closing issues automatically. What a demented idea.
That's because most Github repos are not for collaborative development, but rather for marketing and customer support.
Next should be Jira's ticket about versions across projects.
Wonder if others had the same local names, Nutscape and Internet Exploder.
this was filed against Netscape Navigator
Mozilla Suite rather than Netscape Navigator. This is from 2000 which was well into the Mozilla era and I don't think that Netscape bugs made it into Bugzilla anyway.
Netscape 6 and 7 were reskinned Mozilla Suite. It was Netscape 4 that was (mostly?) pre-Bugzilla.
Wow so this bug is older than Firefox itself
Netscape, Mozilla, Phoenix, Firebird, Firefox.
Me too: I remember, when I was first toying with the idea of building websites as a career, being fascinated by the idea of having a web site where the background was transparent or translucent down to the desktop behind. I always figured you should be able to do something like html { background: transparent; } and have it just work.
It’s worth pointing out that this bug fix doesn’t actually do that. For a start, it’s a preference that can be toggled on by the user or an extension, rather than a default thing that websites can choose. Probably for the best: it’d certainly open up new avenues for clickjacking.
The one long term open bug that irks me the most is that you cannot properly date-format the x-axis of scatter plots in LibreOffice:
https://bugs.documentfoundation.org/show_bug.cgi?id=54132
12 years old. According to the comments, fixing it is discouraged as the code is so "horribly complicated", it would likely cause regressions.
Gotta love it when maintainers are afraid of code they allowed to get merged in.
Maintainers often change (leave/die/hired out/new job).
What one maintainer knew and understood, is often fairy dust/spaghetti to another.
Looks like there was quite a bit of attrition in the early 2010s after Oracle stopped developing their commercial version (and presumably stopped hiring the developers). There's also been people who stuck around, but this was probably a pretty big knowledge drain.
And skill level can vary vastly from one maintainer to the next. I suspect this will become a more and more significant problem as time goes on.
Could have been previous maintainers that allowed it, and now the current maintainers are stuck with it.
This does not bode well for my hopes of LibreOffice getting my favorite features from Excel.
Excel code is likely "horribly complicated" behind the scenes as well.
I looked at the openoffice source code 15 years ago .. and stepped back again. But I think LibreOffice systematically refactored a lot of it. It wouldn't hurt asking for it.
Some things are surprisingly easy to implement. Some things would require a redesign, when you are dealing with very old legacy code..
If you just need a spreadsheet and graphing package, gnumeric is a good choice under Linux.
Hoping they do XDG next. Also been waiting for 20 years [1]
I don't think XDG base dir will ever be fully and universally adopted. It's been years (21 years to be exact). If it wasn't for Arch Linux getting hostile to programs that don't follow (like locking permissions of the root user directory), it probably wouldn't have grown as much as it has recently to what it is now because, honestly, the spec is not actively solving real problems people have. Most of the adoption is happening because people are getting cranky about their $HOME directory layout enough that they are annoying enough to bully maintainers into supporting it, but 99% of users don't give a damn if the program follows XDG base dir or not. It's just making the things arguably "cleaner" according to freedesktop from a spec that hasn't gained wide adoption over 20 years.
I, however, don't like the loosy goosy config/data/cache split like they have it and the implied intent because not everything falls into those buckets and then you don't know the behavior of some system thing (is Dameon going to wipe my cache? are users going to copy the config folder around? what gets backed up exactly?) There is no standard for how the folders are really treated in the spec. Intentionally vague but possibly vague in ways that will break things if people make assumptions.
It's like the /usr split from the root. or /usr/local from the root. Or /opt. Left overs from a bygone era that seem to stick around. Trying to create yet another.
I reluctantly support it in our product, but only when those ENVs are explicitly set, and I 100% ignore XDG's behavior and what it says should be the default on every linux system when it's not set because it's not what other UNIX variants like MacOS expect. Just enough to keep the Arch Linux zealots from flooding our bug tracker each week, literally demanding we adopt it when they account for less than 1% of users. It's hard enough with docs to let users know where to find their files from our product on their system because users don't know what XDG is all the time and XDG for most is not the established convention they expect already. Frankly, there is too much legacy with trying to move everyone over to this spec, especially when it isn't driving some real compelling value for anyone except for folks who want a pristine user directory.
Honestly, we should rethink it entirely and move to a container-based solution where our desktop apps can't escape their little jails (almost like snap apps). Maybe learn from NIX a bit. Admit defeat that will ever get every linux user app in the world to care and adopt XDG base dir (or even user dir). It's hard enough we are supporting Mac and Windows ports that don't follow this behavior. Get away from the UNIX permission model of running the programs under the user and run each program under it's own uid. It's now android works.
I also think app data in general is a mess. I hate the concept that any app I run can just access any other apps' data just because they share uid.
Honestly at this point I just want a clean $HOME.
App sandboxing is indeed the way of the future, and being worked on by e.g. flatpak.
A few points:
- Arch Linux isn't some fringe operating system full of zealots, it's one of the most popular Linux distribution (it was the most commonly used Linux distribution in the Steam hardware survey in April 2024, beating out Ubuntu). I think many people like it precisely because it takes an opinionated stance on issues such as these.
- You characterize people who ask for these features (for example in bug tracker) as "bullying" maintainers - the fact that such requests are common should show you how widespread support is for these ideas. It seems odd to procure feedback about what users want and then say, "well, that's not what they really want, it must just be a vocal minority".
- Directories like /use/local and /opt are not vestigial, they serve specific purposes. I don't think it's fair to call them a "holdover". For example, without /usr/local, how do you separate software compiled and installed by the user vs. from a package manager?
- I agree completely that containerization of apps is the future.
the loosy goosy config/data/cache split like they have it and the implied intent because not everything falls into those buckets and then you don't know the behavior of some system thing (is Dameon going to wipe my cache? are users going to copy the config folder around? what gets backed up exactly?) There is no standard for how the folders are really treated in the spec. Intentionally vague but possibly vague in ways that will break things if people make assumptions.
Can't say I've ever had issues with this regard, either in my own programs or in other programs I use. It always seems clear cut to me which should be used when. Can you give any examples?
Get away from the UNIX permission model of running the programs under the user and run each program under it's own uid. It's now android works.
I don't blame other people if they want stuff like that, but personally I feel too old for that and will be sticking with what I've got (including XDG directories, because I find them easy and aesthetically pleasing.) All the newfangled sandboxing and stateless stuff is too much for me to learn for only academic benifit; I've never been pwned because thus far I have had good judgment with what software to trust. Learning whole new systems that disrupt my established workflows because I'm meant to be paranoid of the programs I choose to run just doesn't seem like a good tradeoff for me, personally.
It would be like ripping down all the walls in my house to install fire proof barriers, when I've been living in this house for 20 years without a hint of fire. If the house were built like that when I got it, then great, but it wasn't so I'm just going to be careful with candles and replacing smoke alarm batteries.
Yep, looking forward to that one!
With such old bugs I often wonder whether it's not best to simply close them. Few people will browse them and many will be "accidentally" closed by reworking of different subsystems. But if they are still relevant somebody will file it, again. If not reopened it's probably not a problem anymore.
Bug Wars II: CADT Strikes Back. ;-)
Yeah, jwz might be a bit weird at times but he is right on this. I don't understand what problem closing bugs solves. If you want to close a bug, check if it doesn't reproduce. And if it doesn't reproduce, give the author the chance to confirm.
A bug report is documentation. It is valuable. It's a gift. If written well enough of course.
If you feel open bug reports clutters your bug tracker, first I would suggest you are watching them from the wrong perspective, and second I would suggest you might need to take advantage of some triage / organization tool (better) like labels or projects.
Open issue doesn't mean "planned" or "will look into this".
Saying this as a software developer. Who has also been reporting some number of issues. Reporting takes time.
I see people say this all the time, it's a harmful bad practice. Don't auto close bug reports after x amount of time.
I've opened a few bugs, mostly surrounding extensions. Bugs from the XUL days still exist today, even though the UI is different and the API is different and everything. It is somewhat astonishing. I filed most of them over 10 years ago.
So no, just closing them because they'll be accidentally fixed isn't the correct argument IMHO. Instead, they should just admit that most stuff will never get fixed and just clutters the list. Even though that hurts.
The problem with that is the dismissal of the time investment by the original filer who may have spent a significant amount of time getting reproducible steps, screenshots, and other relevant information into the bug. It treats users' time as free.
I think there's a subtle but important distinction between _closing_ the old bugs outright, and leaving them open but marking them as "Verify" with a comment like "we're not sure but it may have been fixed with recent work - can anyone confirm if it's still reproducible?"
I wish the bug where the copy option is randomly greyed out even though there is text to copy got finally fixed. It's been driving me insane.
Glad to know I'm not the only one experiencing this
I also wish there was a way to disable the “disable paste” feature.
Worst case, if there is bizarre breakage due to frameworks that reinvent text boxes, have a keyboard shortcut or menu item to type the clipboard contents at 300 characters per minute.
Ctrl + right click may allow you to work around it.
There are some extensions that can help with that:
https://addons.mozilla.org/en-US/firefox/search/?q=enable%20...
Specifically: Absolute Enable Right Click & Copy
I would prefer of course that the underlying issue get resolved, but in lieu this has been an excellent workaround for my needs.
Let's see if it gets fixed in less than 25 years. Mozilla is sometimes too slow by today's fast-paced web environment.
Firefox's Bugzilla is certainly one of the oldest running bug trackers. I'm impressed at how much of the original feel of the bug tracker is still around after all these revisions. It was a pretty hairy, monstrous codebase back in the day.
At one point in 2000 (?) I stood up an instance in our Windows dev shop to replace a home-grown bugtracker built on Microsoft Access/Outlook. It was complex but pretty much one of the best-of-breed bugtrackers for some time. I think that FogBugz was just getting started around then, and those guys were one of the first teams to really consider user experience.
Even today it is hard to beat Bugzilla. In fact, some of the choices available today are so much worse than Bugzilla that I cannot even fathom how they exist. As an example, Dwarf Fortress uses Mantis BT, which is just awful.
On the other hand, FogBugz is one that I have always wanted to try if I ever got the chance.
Whoa, Fogbugz was sold off to a new buyer and Glitch is the only major product in Fog Creek's hands.
They got FU money
I used Mantis on a private project before, and although the UI is a bit on the ugly side and quite outdated, everything worked as expected and it did a pretty decent job at what it promised
I'm still holding hope that thunderbird will actually fetch mail into folders without having to click on them...
I agree it's pretty annoying, no idea why they don't check all by default. You can manually change the setting for each folder (righ click -> properties) or:
https://manage.dihostnet.com/knowledgebase/8/Check-all-IMAP-...
It's half the solution. If you reply to an email in your inbox, the sent email won't often show up in thread until the Sent folder is updated. Either by clicking on the Sent folder, or waiting for the next auto-check.
Right click folder, select "Properties", check "When getting new messages for this account, always check this folder."
On a related note, starting today, I noticed that x.com (fka Twitter.com) is no longer working in Firefox.
I get the following error:
Something went wrong, but don’t fret — let’s give it another shot.
Firefox’s Enhanced Tracking Protection (Strict Mode) is known to cause issues on x.com
Only very remotely related if you squint hard enough though, no?
(sorry for sounding a bit rude, not my intention, I would like to read friendly but I can't find a nice way to point this out and still want to do it - it's just that I wouldn't find it very enjoyable if all HNers started commenting about general / random issues they encountered on some product P in a submission about a specific/historical issue in P - I'm sure we all encountered some issue while using Firefox / any browser at least once, especially with Twitter which screams buggy to me as a distant observer, I remember consistently having to try and refresh pages several times a few years ago to display a 140 character tweet - awful experience)
Well, x.com was working completely fine on my version of Firefox until yesterday so it’s an intentional breakage for Firefox users.
My comment was more of a PSA to other Firefox users who are likely the ones also reading about the bug fix here, so it’s definitely on-topic. I guess you disagree which is fine.
If they don’t fix it, I have to either switch to a different browser or device (mobile) to visit x.com.
The good news is I’ll spend less time there.
Same here.
This also happened about a week ago, but was reverted/fixed within a few hours. So, I'm hoping Twitter will fix this.
Resolution: --- → DUPLICATE
https://bugzilla.mozilla.org/show_bug.cgi?id=1830576 was the ticket with the actual fix. This bug had hundreds of duplicates. And finally Chromium, Safari and Firefox came together to fix it.
The duplicated bug was where the fix was landed, it was just easier to use a new bug rather than discuss things on the 25 year old bug.
I dont recall we had firefox in 99. Even internet explorer , was it there ? good times.
The bug was actually filed just over 24 years ago, and BugZilla rounded up. And back then it was Mozilla before it was Firefox
The bug was originally filed against Netscape Navigator per this comment: https://news.ycombinator.com/item?id=40431738
That's awesome! 28-03-2000 is not 25 years ago, tho.
Yeah. Honestly, I would wait those couple of months and fix it on the silver anniversary... :P
That is an odd way to round it, now that you mention it.
Why so many posts about Firefox bugs getting fixed after N years? https://hn.algolia.com/?q=firefox+bug+years
I think people are amazed and impressed that bugs more than 6 months old aren't just auto-closed with "There's been several new versions since this bug was filed, please check if this still exists on the latest version, and if so file a new bug."
That bug is older than half the audience here... Probably?
no
AWS solves this problem by periodically wiping out old bugs and any mention of them.
The ostrich strategy to avoiding bugs.
Also Firefox: not passing acid3 test
https://en.wikipedia.org/wiki/Acid3
By April 2017, the updated specifications had diverged from the test such that the latest versions of Google Chrome, Safari and Mozilla Firefox no longer pass the test as written. Hickson acknowledges that some aspects of the test were controversial and has written that the test "no longer reflects the consensus of the Web standards it purports to test, especially when it comes to issues affecting mobile browsers".
It warms the cockles of my heart to see this kind of thing. Happened to me recently with a 24 year old firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=62151
Fuck, I remember being stumped by this
Holy shit, Firefox has been around for 25 years?
No, this was filed for originally Netscape Navigator which codebase evolved into modern Firefox.
At least they don't sweep bugs under the rug after 6 months of inactivity as many projects.
I believe the common term for this is "bug bankruptcy".
And when teams declare bug bankruptcy too often, it's called "bug insolvency". I have only seen "bug insolvency" once, but "bug bankruptcy" seemed to be commonly used.
There are a few other long running software. What's the longest age of a fixed emacs bug, for instance?
Here's one older than the FF one: https://eshelyaron.com/posts/2024-02-10-fixing-a-twenty-six-...
Updated version of patch. r=sfraser@netscape.com
Does that domain even exist anymore?
Sounds like maybe they should rewrite firefox in rust.
Textareas are so overlooked, they feel really like 1990s, yet there is no real alternative with spellchecking and os integration.
5 more years than what Phil Leotardo spend in the can, and 7 more than what it took to get a file picker thumbnail in Gnome.
Closed: 24 years ago → 6 hours ago
BugBot was on to something: https://bugzilla.mozilla.org/show_bug.cgi?id=33654#c190
"The severity field for this bug is relatively low, S3. However, the bug has 27 duplicates, 103 votes and 91 CCs. :emilio, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation."
Feels like my experience waiting for Microsoft or Jetbrains to fix bugs
Related from last August:
Happy 25th Birthday to Bugzilla
I like it iff I can hover over the human readable version to get the actual timestamp.
Better the opposite - date by default and on hover human readable. People would more likely want to copy the actual date than the human readable delta.
Agree to disagree :) The "human readable" is better at a glance, and timestamps are better when I care about the specifics.
I agree that this is true when copying, but text is primarily for reading, not copying.
I find dates more readable as an ordered list of numbers. A thread can be quickly scrolled down through while seeing >2001 then eventually >2024 at the same x-position on the page. Same goes with the month then day.
Anyway, in the context of a comment/activity thread, how long ago from today that an entry was tends to be less important than the age of the comment relative to the other comments.
If all the comments are 1 year ago then it is not very informative on the relative order
How is this "better at a glance"?!
This can have problems on mobile
Yes, but I think the solutions work fine; tap, hard press, whatever.
Don't get me wrong, I share the annoyance with interfaces where I have no way to find the actual timestamp. It's better to only have a timestamp than to only have the "human readable" version with no way to get the timestamp. But (in my opinion) the best is to have the human readable version, with a way to get at the timestamp.
I think the problem is that the mechanism to trigger mouse-hover is not clear on a touchscreen - there are several different ways that need to be remembered and tried, as evidenced by your comment.
Yes, but I think the venn diagram of people who really want to see a timestamp and people who are willing and able try a few different things to find it is pretty close to being a circle.
Hover over the date to see the exact day and time.
Hover? I'm on mobile...
This is kind of an aside, but hover is a perfectly valid UI mechanism, and I intensely dislike the trend of kneecapping the UI just to make it work on a touch screen.
Some things just don't work well if you don't have a mouse. That doesn't mean we should throw them away. It just means that sometimes you need a mouse for real work. There's nothing wrong with that.
To each their own, I absolutely despise anything popping up, ever.
Stuff appearing and disappearing as I move my mouse around angers me, and I get even more annoyed when things pop up if I put my mouse somewhere to park it.
A full blown conniption fit happens if I park my mouse, start to read something, and a popup thing gets in the way. The neighbours know when that happens.
I think the point is more that if a feature requires a mouse to work, maybe that mode should be the optional path so it still works on mobile.
At least on bugzilla, I’m able to tap and hold to get the same effect.
In Outlook for Mac if I hover "Yesterday" in the tooltip I get... "Yesterday".
I see now it wasn’t clear, but I was referring to bugzilla. I don’t use Outlook.
Gitlab shows this relative date. I repeatedly have this issue where I'm trying to look through commits and I have to mouse over every single commit repeatedly while trying to figure out when something was changed in relation to other changes. So I mouse over one, mouse over the next, go back to the previous one, forget what the other one was, mouse over that, then mouse over a fourth and repeat.
Who came up with this insane bullshit?
It'll show me a bunch of commits all made 4 days ago. I have no idea what day that was. Was it Monday? Wednesday? I have logs from the 16th, does Gitlab think that was 4 days ago or 5?
Even worse when it's wrong, Discogs insists that October 2021 is "over three years ago"
Earlier this years, Github would routinely say "2 years ago" for comments made 11 months ago.
I've experienced (not on GitHub) things that happened 729 days ago being "one year ago", which is similarly incorrect
It's not correct, but at least not unexpectedly so
This seems on brand for Discogs and their awful design changes lately. They also replaced fast-loading pages with super slow AJAX requests (reminiscent of the equally disastrous C2 Wiki's similar design update from years ago). Discogs also is now randomly censoring album art until you log in for some reason, but only for the main image on a release page and not in the dozen of other places where the album art appears on a page otherwise </rant>
"Xenoamorphous 4 minutes ago", got it. Edit: 5 minutes ago.
Ha! Maybe, maybe for something happening in the past day or so it’s ok, esp. due to timezone conversion confusion.
But for anything older than that, just show me the date!
Personally it is more about avoiding big relative errors: 1 month ago can be between 10 and 45 days ago (maybe, nobody knows how the rounding works). 8 months ago is less of problem
I think you'll find it was 1 hour and 5 minutes ago.
I, however, really struggle with this. I have a real problem with any concept of dates or the passing of time.
Then show a detailed timestamp in a tooltip.
Seriously, I cannot wait for this trend to die. It makes a huge difference if an email was received at 6:00 a.m. or if it was received at 11:00 p.m. that day. Simply saying "yesterday" is not good enough!
I like my beer cold and my time stamps precise.
Design over function at microsoft.
The new outlook 365 seems to have removed the time component from older entries so even when they show you the date, it won't include the time. If you have 20 emails per day, you'll have to open them one by one until you find the one you need.
I wish there is a way to revert to the old behavior but microsoft support says we don't need this.
It helps to avoid timezone details within a day or two. I agree "a month ago" is pretty bad, but I haven't seen that.
But it's good to say "1hr ago" if I send an email from New York to San Francisco.
Holy shit. Human readable.
The actual timestamp/email address/detail is what I need to see to make decisions!