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!
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.
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.
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.
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.
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.
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.
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.
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.
Like I said, agree to disagree, diff'rent strokes for diff'rent folks and all that, but to me, after a day, the most pertinent at-a-glance information there is "this was received yesterday". I definitely think it's more useful for more recent things that can say "37 minutes ago" or "3 hours ago", but to me, "yesterday" is also useful. (I might prefer it if it said "yesterday morning" and "yesterday evening" or something like that, but I rarely care about the exact time, after a day.)
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.
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!
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.
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>
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.
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?
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
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.
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
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..
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.
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.
> 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.
- 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.
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.
It looks weird to me too, but it's hardly indecipherable. You have a four-digit year (2000), there's only 12 months in the year, so the "28" is the day and "03" is the month.
In ISO 8601 format, it'd be 2000-03-28. In American written format, it'd be March 28, 2000.
ISO8061 or RFC3339 are the only correct date formats; though if for some forsaken reason your ledger starts accounts on the right hand page and treats the left as part of a prior record, then placing the least frequently changing part of the date to the edge of the page is good as a primitive index.
I've never encountered that particular format before, and based on that, I'll question the claim of "most common", but even still, I could understand what was meant.
And I assume this is the usual one in Europe in general for a human-readable context, like within a sentence. And as you said, dashes only in YYYY-MM-DD which is hopefully used always in any data context.
I never knew that, actually. I developed a habit of writing my dates with dashes instead of slashes because I thought the latter looked too much like the number 1. Makes me wonder how many people I've confused after they read paperwork I dated. I currently do ISO order with forward-slash as a separator, which might be similarly confusing.
There are systems out there that do YYYY/DD/MM. AFAICT YYYY-DD-MM is only used by evil pranksters, so a date that starts with a 4 digit number and uses dashes is relatively safely assumed as YYYY-MM-DD.
> It does in my jurisdiction. 2/8/24 is usually m/d/y, 2-8-24 is usually d-m-y
Where is that?
I would guess this is more like 'most people use /' and 'most people where I am use month first'; therefore those using - separation are weirdo Europeans/rest of world putting the day first.
DD-MM-YYYY isn’t as logical as you think. If it was actually consistent then it would be 82-20-0002. Only ISO 8601 and friends are consistently arranged. Anything else is simply a convention that makes sense to those accustomed to it.
But it's actually worse than that: while both the car and the horse will correctly move you from A to B, you can't cite an LLM output as a source and can't use it to check something. You can use it as a source of inspiration at best.
Here your LLM output is wrong. Someone from Germany wrote they most commonly use dots, in France we use slashes and I think countries around all do one of the other.
So yes, there's no way around doing it like we always did: find a reputable source to back a statement. And ChatGPT does not do this.
When evidence is needed, "often correct enough" is not sufficient. You need reliable and correct for sure.
I assume you understand how LLMs work? Probabilistic word generation? That can't possibly be used as a source. It literally works by making up things that look probable. It can be used to find a source, but you still need a source.
The LLM might be correct often enough, but you'll only know the LLM is correct in the case at hand by checking at a source…
> If ChatGPT behaves like a roulette to you I'll attribute that to operator error.
I never used it. I know LLMs can be impressive and useful, but sourcing is not among the use cases. The operator should be operating the right tool for the job in the first place.
Shit I say is hopefully correct often enough, but I still can't use myself as a source.
I'm not implying frequency, and it does apply here, you cited ChatGPT as an evidence, in this very discussion. I'm speaking about this, specifically. This comment where you do this was downvoted and flagged to death. And I did mention LLM can be useful. What are you trying to do here?
"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."
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.
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:
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.
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.
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."
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.
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'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.
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.
> 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".
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!