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!
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.
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.
I like my beer cold and my time stamps precise.
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.
I, however, really struggle with this. I have a real problem with any concept of dates or the passing of time.
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?
But for anything older than that, just show me the date!
The actual timestamp/email address/detail is what I need to see to make decisions!
But it's good to say "1hr ago" if I send an email from New York to San Francisco.
But use ISO 8601 or a month name FFS — dd/mm or mm/dd is not always obvious.
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.
On the other hand, FogBugz is one that I have always wanted to try if I ever got the chance.
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.
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..
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.
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.
Honestly at this point I just want a clean $HOME.
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.
Happy 25th Birthday to Bugzilla
"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."
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
(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)
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.
This also happened about a week ago, but was reverted/fixed within a few hours. So, I'm hoping Twitter will fix this.
https://manage.dihostnet.com/knowledgebase/8/Check-all-IMAP-...
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 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?"
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.
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.
Does that domain even exist anymore?
> 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".
