17 year old Firefox feature request fixed(bugzilla.mozilla.org)
bugzilla.mozilla.org
17 year old Firefox feature request fixed
https://bugzilla.mozilla.org/show_bug.cgi?id=259640
280 comments
> 17 years ago
"Nearly half my age," said Emacs.
"Nearly half my age," said Emacs.
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.
are we off by one ?
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?
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.
[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.
Emacs of course ;)
Gosh, "old timer" :(
Gosh, "old timer" :(
Apologies for my poor choice of wording!
Here in South Africa we typically use "old-timer" to refer to someone who is very experienced.
My comment was expressed with the utmost respect I assure you :)
Here in South Africa we typically use "old-timer" to refer to someone who is very experienced.
My comment was expressed with the utmost respect I assure you :)
I didn't take it as a derogatory label. My emoji was just my own self reflection on the years gone by.
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
https://www.cs.cmu.edu/~coke/history_long.txt
What a wonderfully entertaining read that was :)
Sounds like the culture in the CMU CS department was pretty great.
Thank you for sharing this historical gem with us.
Sounds like the culture in the CMU CS department was pretty great.
Thank you for sharing this historical gem with us.
edlin
Why fix what ain't broke? /s
Why fix what ain't broke? /s
Also, conversely whom Emacs is attracting these days. One interesting data point i came across is this philosophy dude protesilaos.com/ . Amazing youtube videos on Emacs and he has unique view from the point of philosopher for Emacs.
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.
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.
GNU Emacs was released in 1985. Other variants of Emacs date back to the 70s.
> Initial release 1976; 45 years ago
https://en.wikipedia.org/wiki/Emacs
https://en.wikipedia.org/wiki/Emacs
Today I thought I was learning I’m older than emacs, but learned I’m only barely younger and that’s just fine for me.
To think I was still using Eclipse a scant 7 years ago...
Oh wow, Eclipse.. That reminds me, I was using Netbeans eons ago (2010 more precisely xD). For this reason, I'm using the Netbeans key mappings in all my editors. I kinda feel bad for those editors, and I hope they still have an active user base, but oh well, it's survival of the fittest I guess.
Ah, someone else !
I live in fear they will be removed from PyCharm - every time I update one of the Jetbrains editors and the Netbeans bindings aren't there, I'm lost.
I live in fear they will be removed from PyCharm - every time I update one of the Jetbrains editors and the Netbeans bindings aren't there, I'm lost.
Don't worry too much about it. It will take 1-2 weeks of excruciating pain, changing your muscle memory, but that's it.
Remember, people learn dvorak after a life time of qwerty... and I'm sure they aren't (all) masochists.
Remember, people learn dvorak after a life time of qwerty... and I'm sure they aren't (all) masochists.
Your comment reminded me that I have now been writing code for about a decade, as I used Netbeans as my first IDE in high school.
I was forced to use Eclipse for a while ~2010, never liked it.
It's funny to look at how many editors one comes across over the years. My first one was Borland C++ as a kid. Then came a mix of Visual C++ and Bloodshed Dev C++ during high school. During university I tried a bunch of things but mainly nano, gedit, Visual Studio, and Eclipse. In my early career (2013) I finally got into Vim and haven't looked back since.
I did try out Rider a little over a year ago. It was really good and I'm impressed with some of its features. But it wasn't enough to make me switch.
It's funny to look at how many editors one comes across over the years. My first one was Borland C++ as a kid. Then came a mix of Visual C++ and Bloodshed Dev C++ during high school. During university I tried a bunch of things but mainly nano, gedit, Visual Studio, and Eclipse. In my early career (2013) I finally got into Vim and haven't looked back since.
I did try out Rider a little over a year ago. It was really good and I'm impressed with some of its features. But it wasn't enough to make me switch.
There's an official Vim plugin by Jetbrains for all Jetbrains IDEs (including Rider).
I find it a great way to combine the strengths of Vim with the strengths of a full IDE.
I find it a great way to combine the strengths of Vim with the strengths of a full IDE.
Here's another vouch for IdeaVIM. It's got 99% of the VIM that I use, and is actively developed.
I still use it. I always hear these raving praises for IntelliJ so I guess I have to force myself to move to IntelliJ. I tried a couple of times, but always fell back to Eclipse due to familiarity.
What do you think is the biggest difference between the two?
What do you think is the biggest difference between the two?
I suggest giving IntelliJ a shot but, honestly, if you prefer Eclipse then stick with it. I originally switched because at the time IntelliJ had better code navigation, better version control support, better static analysis support, and an overall much better aesthetic IMO (especially in dark mode). Things might have improved in Eclipse since then, but I haven't tried it in a long time. I think the last Eclipse version I used was Juno.
I do a lot more Python work than Java nowadays so I use PyCharm much more than IntelliJ, though they share a lot in common. Aside from those, the only IDE I really ever use is GNAT Studio for work. I suppose I used Android Studio for a while, but that's basically just IntelliJ with some Android-specific features bolted on.
I do a lot more Python work than Java nowadays so I use PyCharm much more than IntelliJ, though they share a lot in common. Aside from those, the only IDE I really ever use is GNAT Studio for work. I suppose I used Android Studio for a while, but that's basically just IntelliJ with some Android-specific features bolted on.
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't hiring, sigh) in at least four languages (JS, PHP, TS and Go, it's an older application and a rebuild I'm working on), and intellij has no qualms with it whatsoever.
I even set it to PHP 5.2 mode so it warns me when I try to use `[]` to initialize an array.
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't hiring, sigh) in at least four languages (JS, PHP, TS and Go, it's an older application and a rebuild I'm working on), and intellij has no qualms with it whatsoever.
I even set it to PHP 5.2 mode so it warns me when I try to use `[]` to initialize an array.
Ack...that's some old PHP
Trying to cry in eclipse editor, but its not responding :(
I’ve been using IntelliJ since version 2. :-) My favorite developer tool of all. Cheers!
oh god, I never knew how much I needed a scrollbar gutter for search results. So great.
This comment just makes me angry to think about all the time I wasted using Eclipse without knowing that a better alternative existed.
I feel bad for leaving Eclipse. It was exceptional at the time, with its partial-class compiler, you could execute the JUnit on it even if the rest didn’t compile, something IntelliJ still refuses.
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.
Looking at you, every random GitHub project ever.
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.
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 opening up new tickets for the same thing, and the triagers will have to either point them to the old ticket, or the discussion about whether or not to do it has to be restarted.
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 opening up new tickets for the same thing, and the triagers will have to either point them to the old ticket, or the discussion about whether or not to do it has to be restarted.
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.
I totally agree.
There’s just this thing called “reality” and unless your ticket by coincidence ends up catching the eye of someone who can actually do something about it, it will be left to rot. And because nobody will bother looking at the oldest ticket known to man™, the close-bot may as well close it. Tens of thousands of untriaged reports aren’t helping anyone.
There’s just this thing called “reality” and unless your ticket by coincidence ends up catching the eye of someone who can actually do something about it, it will be left to rot. And because nobody will bother looking at the oldest ticket known to man™, the close-bot may as well close it. Tens of thousands of untriaged reports aren’t helping anyone.
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.
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.
Is it a human closing it or a bot? If you run an open source project there's a natural tendency to install a bot to auto-close all of the issues which people open because they didn't read the docs, want you to do free consulting for their business, have an irreproducible bug report, etc. and since most projects are short on labor that makes it somewhat inevitable that someone will enable the bot first and never get around to configuring it to, for example, not close an issue tagged as verified.
A bot, but
> someone will enable the bot first and never get around to configuring it to, for example, not close an issue tagged as verified.
I don't understand this part. Aside from the fact that it's trivial to exclude certain tags (it's the same config file, and it's in the first example they give), doing this effectively makes your issue tracker useless as an issue tracker. Why not completely disable the issue tracker instead then?
> someone will enable the bot first and never get around to configuring it to, for example, not close an issue tagged as verified.
I don't understand this part. Aside from the fact that it's trivial to exclude certain tags (it's the same config file, and it's in the first example they give), doing this effectively makes your issue tracker useless as an issue tracker. Why not completely disable the issue tracker instead then?
Oh, I'm not saying it's great. What I'm saying is that the process often looks like this:
1. Release a project on GitHub
2. Get busy with other things / deluged in issues
3. “I don't have time for this. Let me install the auto-close bot!”
4. Issues get closed
5. [sometimes never] “I better configure the auto-close bot to only act on untriaged issues”
1. Release a project on GitHub
2. Get busy with other things / deluged in issues
3. “I don't have time for this. Let me install the auto-close bot!”
4. Issues get closed
5. [sometimes never] “I better configure the auto-close bot to only act on untriaged issues”
They meant Mozilla having revenue, not GitHub.
So did the person you're replying to.
I half-seriously suggested that a project I used to care about set up a cron job to delete requests older than a year automatically.
The rationale was that they only did that sporadically every few years, when some other change mooted the issue. If they ignored feature requests on a schedule, it would better manage external expectations.
See also, The CADT Model (but copy-paste the link in to your browser bar to avoid a bit of unrelated commentary):
https://www.jwz.org/doc/cadt.html
The rationale was that they only did that sporadically every few years, when some other change mooted the issue. If they ignored feature requests on a schedule, it would better manage external expectations.
See also, The CADT Model (but copy-paste the link in to your browser bar to avoid a bit of unrelated commentary):
https://www.jwz.org/doc/cadt.html
Please remove the link.
The link is good and insightful, if you copy-paste it into the browser bar. If you click it it redirect to a fairly tasteless image complaining about being linked from HN.
The whole thing is less than a page long and dead simple, I'm just going to copy/paste the entire page verbatim:
> The CADT Model
>© 2003 Jamie Zawinski <[email protected]>
>In February 2003, a bunch of the outstanding bugs I'd reported against various GNOME programs over the previous couple of years were all closed as follows:
>>Because of the release of GNOME 2.0 and 2.2, and the lack of interest in maintainership of GNOME 1.4, the gnome-core product is being closed. If you feel your bug is still of relevance to GNOME 2, please reopen it and refile it against a more appropriate component. Thanks...
>This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version.
>I'm so totally impressed at this Way New Development Paradigm. Let's call it the *"Cascade of Attention-Deficit Teenagers"* model, or *"CADT"* for short.
>It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8?
>But that's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again.
[random GIF of a compass, that links to the homepage]
> The CADT Model
>© 2003 Jamie Zawinski <[email protected]>
>In February 2003, a bunch of the outstanding bugs I'd reported against various GNOME programs over the previous couple of years were all closed as follows:
>>Because of the release of GNOME 2.0 and 2.2, and the lack of interest in maintainership of GNOME 1.4, the gnome-core product is being closed. If you feel your bug is still of relevance to GNOME 2, please reopen it and refile it against a more appropriate component. Thanks...
>This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version.
>I'm so totally impressed at this Way New Development Paradigm. Let's call it the *"Cascade of Attention-Deficit Teenagers"* model, or *"CADT"* for short.
>It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8?
>But that's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again.
[random GIF of a compass, that links to the homepage]
Thank you!
> I'm so totally impressed at this Way New Development Paradigm. Let's call it the "Cascade of Attention-Deficit Teenagers" model, or "CADT" for short.
Sounds like the content is just as mature and insightful as the HN ddos redirect image. I see why objecting to being linked an image of a hairy ball in a 2011 image macro was wrong of me.
> I'm so totally impressed at this Way New Development Paradigm. Let's call it the "Cascade of Attention-Deficit Teenagers" model, or "CADT" for short.
Sounds like the content is just as mature and insightful as the HN ddos redirect image. I see why objecting to being linked an image of a hairy ball in a 2011 image macro was wrong of me.
If the author complains about a HN ddos, then why does everyone suggest evading his ddos protection? It seems like reuploading the content works out better for everyone. It's just plain lazy to post a raw link to that site on this forum.
Turn off cross-domain referer sending: https://wiki.mozilla.org/Security/Referrer
It seems to work perfectly fine either way for me. Not sure what the complaint is?
I think it doesn't redirect if you have visited the site before. Otherwise you get redirected to https://cdn.jwz.org/images/2016/hn.png
[deleted]
Why? You can just copy the link, open a new tab, past it in the URL bar and see the material...
oh, I love jwz's HN DoS mitigation image.
Oh it's not DoS mitigation, he really just hates HNers. Completely understand him.
yeah, that makes sense.
Did anybody ever find the secret?
Take a look at the root pages html source
Take a look at the root pages html source
Also Gnome. Always cracked me up. Like I'd make this issue with like all the details reported and everything. ESR would have wept. And then "Does this issue still occur in Gnome 3?" and closed a week later all while I'm on vacation. Homie, this sat here for like 5 years, surely you can be a little patient.
Anyway, that taught me not to report something that's not a game-ender. Which is probably what they want too, so I guess we're all in some sort of equilibrium.
Anyway, that taught me not to report something that's not a game-ender. Which is probably what they want too, so I guess we're all in some sort of equilibrium.
That's kind of sad though, since that type of issue is really valuable if the project is under active development.
jwz has nicknamed this the CADT model, for "cascade of attention-deficit teenagers".
(edit: _jal beat me to it.)
Few things are as infuriating as taking the time to write a great bug report just for it to be ignored or autoclosed.
(edit: _jal beat me to it.)
Few things are as infuriating as taking the time to write a great bug report just for it to be ignored or autoclosed.
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 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.)
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.)
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 report.
At the same time, I don't want to leave open years-old issues about a part of the program which has been heavily modified, because they are likely outdated, and low priority to begin with.
The best compromise for the moment seems to be leaving them open, tagging them as outdated or someday/maybe, and filtering out those tags. This is far from ideal, because the filter isn't sticky, so you either have to bookmark it or continually re-apply it.
But it would be really nice if bug trackers created three visual bins to dump things into, where the middle bin is this nebulous "stuff" that's not quite groomed well enough to be actionable but also not finished enough to be closed. (Note: also, "closed" should be subdivided into "implemented" and "rejected" with different visual statuses, like Merge Requests often are distinctly coloured by merged vs closed -- but this is not a separate bin).
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 report.
At the same time, I don't want to leave open years-old issues about a part of the program which has been heavily modified, because they are likely outdated, and low priority to begin with.
The best compromise for the moment seems to be leaving them open, tagging them as outdated or someday/maybe, and filtering out those tags. This is far from ideal, because the filter isn't sticky, so you either have to bookmark it or continually re-apply it.
But it would be really nice if bug trackers created three visual bins to dump things into, where the middle bin is this nebulous "stuff" that's not quite groomed well enough to be actionable but also not finished enough to be closed. (Note: also, "closed" should be subdivided into "implemented" and "rejected" with different visual statuses, like Merge Requests often are distinctly coloured by merged vs closed -- but this is not a separate bin).
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
This assumes that the bug creator can be bothered to review the bug and type every n weeks "still happens", with n unknown and variable in general. This makes sense for an organization with clear processes where the value of n is well-known to all stakeholders, but comes off as unwelcoming and offputting for users who want to contribute in their free time to improve their favorite applications.
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). Some of the bugs are still encountered by new users, unfortunately, but are not fixed yet since they are not critical enough or have enough impact compared to other bugs.
To his credit, that manager also came up with a more-or-less effective formula to rate the bugs according to their importance based on several criteria. Which helps a lot with the upkeep and with planning ahead. And occasionally, one of the very old bugs will be critical enough for a large enough group of users that it will rise up in the ratings to be fixed.
I also set aside time for bug grooming once in a while, closing bugs which were fixed or are no longer relevant. Unfortunately. at this point we are a small team with only 2 experienced devs (the rest are very good but are relatively new graduates and/or without a lot of experience and require supervision) and close to 5000 open bugs and requests, and a steady stream of new feature requests and bug reports. We also have too many internal users for our own good.
It's tough. But the dude abides.
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). Some of the bugs are still encountered by new users, unfortunately, but are not fixed yet since they are not critical enough or have enough impact compared to other bugs.
To his credit, that manager also came up with a more-or-less effective formula to rate the bugs according to their importance based on several criteria. Which helps a lot with the upkeep and with planning ahead. And occasionally, one of the very old bugs will be critical enough for a large enough group of users that it will rise up in the ratings to be fixed.
I also set aside time for bug grooming once in a while, closing bugs which were fixed or are no longer relevant. Unfortunately. at this point we are a small team with only 2 experienced devs (the rest are very good but are relatively new graduates and/or without a lot of experience and require supervision) and close to 5000 open bugs and requests, and a steady stream of new feature requests and bug reports. We also have too many internal users for our own good.
It's tough. But the dude abides.
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.
Closing bugs just to make dashboards/metrics look better is wrong; either adjust the dashboard or fix the bugs.
For open repositories like this I certainly agree. And when I worked at a smaller company with no dedicated QA team we never closed bugs, either.
But in game development with dedicated QA I feel such scrubs are necessary because when they're not done you end up wasting days just confirming that old bugs can no longer be reproduced and flagging them to be closed. Most bugs which linger are symptoms of other bugs which have been addressed.
If they're still there they will almost certainly be found again by QA the moment you close it. In fact, old bugs often even have newer duplicates.
But in game development with dedicated QA I feel such scrubs are necessary because when they're not done you end up wasting days just confirming that old bugs can no longer be reproduced and flagging them to be closed. Most bugs which linger are symptoms of other bugs which have been addressed.
If they're still there they will almost certainly be found again by QA the moment you close it. In fact, old bugs often even have newer duplicates.
Just do what they do where I work, move to a new tracking product, if you really care then you have to go and open bugs in the new (more annoying to use) system :)
We're on our 3rd or 4th now.
We're on our 3rd or 4th now.
I have seen projects where the developer(s) would say things like: "This feature request sounds good to have but we don't have the time for this now. So, I'm closing it. Could you please create it again in 6 months?"
I'm lost for words. Can't you just put a tag and park it? What is this obsession about keeping the issue count low?
I'm lost for words. Can't you just put a tag and park it? What is this obsession about keeping the issue count low?
I hope they also finally allow black on yellow highlighting again (like pretty much every other browser), which hasn’t been possible since Firefox 3.5 in 2009.
https://bugzilla.mozilla.org/show_bug.cgi?id=505089 http://forums.mozillazine.org/viewtopic.php?p=7018785
https://bugzilla.mozilla.org/show_bug.cgi?id=505089 http://forums.mozillazine.org/viewtopic.php?p=7018785
btw black on yellow is used for the <mark> tag. it makes sense to not use the same colors for firefox chrome
Not to get too greedy, but maybe do the 21 year old “Use native context menus on Mac OS” next?
https://bugzilla.mozilla.org/show_bug.cgi?id=34572
https://bugzilla.mozilla.org/show_bug.cgi?id=34572
Looks like it's in progress. Also native "rubberband" scrolling in macOS is in progress as well. Excellent!
Making it also respect dark mode in alerts would be nice.
Yup, I'm waiting for that one as well. Open/save/print dialogs seem to be using native components, but I'm guessing they link to old versions of AppKit because they don't respect the system setting for dark mode either.
But all in all, I'm pretty happy with Firefox. This is a very minor thing for me.
But all in all, I'm pretty happy with Firefox. This is a very minor thing for me.
This makes me very happy. It sounds dumb but I've considered switching from Firefox just because of the context menus.
Why is jira.mozilla.com private?
Also, why is there a jira.mozilla.com at all, and why is there a jira.mozilla.COM?
You don't know about non-profit shenanigans? Ok, so, let me tell you...
There are two entities: the Mozilla Foundation--which is what everyone thinks of when they hear "Mozilla" and think Mozilla is a non-profit--and the Mozilla Corporation--which is what actually comprises the bulk of Mozilla's operations.
The Foundation does practically nothing. Your donations to the Foundation don't go towards development of Firefox, they mostly go to pay the salaries of the Foundation employees, who mostly work to... raise money for the Foundation to pay their salaries. This is a problem with a large number of non-profits in general--that most of the money raised is just spent on maintaining the fundraising apparatus. But in particular at Mozilla, it's a drop in the bucket of what Mozilla Corporation needs to keep operating.
The vast majority of the actual software development work is done under the corporation. And the vast majority of funding that the corporation has comes through a search advertising deal that Mozilla struck with Google.
There are two entities: the Mozilla Foundation--which is what everyone thinks of when they hear "Mozilla" and think Mozilla is a non-profit--and the Mozilla Corporation--which is what actually comprises the bulk of Mozilla's operations.
The Foundation does practically nothing. Your donations to the Foundation don't go towards development of Firefox, they mostly go to pay the salaries of the Foundation employees, who mostly work to... raise money for the Foundation to pay their salaries. This is a problem with a large number of non-profits in general--that most of the money raised is just spent on maintaining the fundraising apparatus. But in particular at Mozilla, it's a drop in the bucket of what Mozilla Corporation needs to keep operating.
The vast majority of the actual software development work is done under the corporation. And the vast majority of funding that the corporation has comes through a search advertising deal that Mozilla struck with Google.
According to https://www.mozilla.org/en-US/foundation/annualreport/2019/ this is not at all the case.
It’s probably private because it is used for internal systems.
It’s probably .com because it’s for Mozilla Corporation as opposed to Mozilla Foundation.
It’s probably .com because it’s for Mozilla Corporation as opposed to Mozilla Foundation.
Still interesting that they internally dont use bugzilla. I wasnt aware.
I suspect the vast majority of bugs are exclusively using Bugzilla. Maybe they use Jira for roadmapping or security bugs.
Other open source projects plan in public. Bugzilla can restrict viewing security bugs.
Some project managers use Jira. Developers use Bugzilla.
> Some project managers use Jira.
My heart goes out to those wretched souls.
My heart goes out to those wretched souls.
The issues with Jira links don't have obvious connections to internal systems. I think the FIDEFE project is UI related.
[deleted]
That's older than me
I really miss Camino.
Now that’s a name I’ve not heard in a long time.
Yup, a long, long time ago, in a galaxy far, far away.
For its time it was a great little browser. I was going to do some bug fixing on it. But then I saw that it required Corba ORB to build. So I let out a long, low moan and, shivering uncontrollably, filed that dream under never going to happen.
For its time it was a great little browser. I was going to do some bug fixing on it. But then I saw that it required Corba ORB to build. So I let out a long, low moan and, shivering uncontrollably, filed that dream under never going to happen.
Is that talking about the right-click menus, or something different? The right-click menus look and act native to me.
It's the right click menus.
99% of the time I use "Look Up" which is the top item in native macOS context menus (for selected text). It's really annoying when your browser is missing it.
This is likely a separate ticket, but Firefox ignores macOS' built-in text replace which I use for expanding text like my email address.
This is likely a separate ticket, but Firefox ignores macOS' built-in text replace which I use for expanding text like my email address.
This is what the right-click menu looks like in Firefox on macOS [1]. Compared to the right-click menu from Safari on the same machine [2], you can see several differences. The most notable one is that the Firefox menu is not theme-aware, rendering a light-themed context menu even though the OS is in dark mode. Next, the padding around the menu is incorrect compared to a native menu. It also looks like the font is maybe a different size. Finally, the drill-down arrow on the Firefox menu doesn't match the native one.
[1] https://ibb.co/0hRpSBB [2] https://ibb.co/wwhCypT
[1] https://ibb.co/0hRpSBB [2] https://ibb.co/wwhCypT
I also want to add that the behavior is different: holding the right mouse button then releasing closes the native context menu, but doesn't close the Firefox context menu. Going into "mission control" closes the native context menu, but not the Firefox context menu. There are a few other differences as well.
Basically, they are not at all the same.
Basically, they are not at all the same.
I've been following this and there's been a lot of activity there lately. Let's hope we get it before its 25th anniversary.
Or the eight-year-old "can't import certificates into mobile Firefox" which makes the browser unusuable in several contexts:
https://bugzilla.mozilla.org/show_bug.cgi?id=868370
https://bugzilla.mozilla.org/show_bug.cgi?id=868370
Now Mozilla, bloody Firefox for Android cannot save the page anymore - not as MHTML, not as PDF. How can such a basic function just disappear?
I also find this painful and have switched to iceraven, a fork of Firefox Android that supports arbitrary addons, and use SingleFile to save webpages as html files.
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
* check own RSS feeds *
Nope, still alive
Google Reader ≠ RSS.
I used that all the time. Saving an entire webpage as just one single file with all images and resources embedded was a terrific way to archive pages and resources in research. Of course pdf was works great too but you lose the flow of a browser.
I certainly don't use it since it's gone, I have to save pdf on desktop and then rsync it to the phone.
Wow, that's a feature that I've been really missing since I switched to Firefox from Opera.
Poor Keith, reported it 17 years ago and then vanished in 2005 missing out on the long journey of his feature request.
https://bugzilla.mozilla.org/show_bug.cgi?id=259640
https://bugzilla.mozilla.org/show_bug.cgi?id=259640
Looks like is now Software Engineer at Stripe. I hope someone lets him know his ticket is closed.
One of the most voted for issues is closed WONTFIX: single click selects all in address bar and search box.
I use Firefox exclusively and this is the single most annoying change they made for no apparent reason. So annoying.
https://bugzilla.mozilla.org/show_bug.cgi?id=1621570 https://bugzilla.mozilla.org/buglist.cgi?votes=133
I use Firefox exclusively and this is the single most annoying change they made for no apparent reason. So annoying.
https://bugzilla.mozilla.org/show_bug.cgi?id=1621570 https://bugzilla.mozilla.org/buglist.cgi?votes=133
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 before I begin typing.
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 before I begin typing.
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 probably use the select-all-then-arrow trick anyway.
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 probably use the select-all-then-arrow trick anyway.
If you're on a Mac, Ctrl-A and Ctrl-E will send the cursor to the start/end of the line (respectively), just like in Emacs.
The use of Cmd instead of Ctrl for CUA shortcuts (and the resulting ability to use Emacs-style shortcuts without issue) is one of the few macOS features that I wish would propagate to other operating systems. The only other OS that comes close with this sort of usability is Haiku (which allows configuring either Ctrl or Alt for the CUA modifier, with Alt by default).
The use of Cmd instead of Ctrl for CUA shortcuts (and the resulting ability to use Emacs-style shortcuts without issue) is one of the few macOS features that I wish would propagate to other operating systems. The only other OS that comes close with this sort of usability is Haiku (which allows configuring either Ctrl or Alt for the CUA modifier, with Alt by default).
Just use the Home or End keys.
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.
Holy crap, I just realized this is why I've pasted the text instead of URL all these years!
You're referring to selection1, not the clipboard.
There is (for me, on Arch) also a selection2, which I haven't investigated further.
Notably Ctrl+C/Ctrl+V operate on the clipboard, while selection and middle-click operate on (at least) selection1.
Notably Ctrl+C/Ctrl+V operate on the clipboard, while selection and middle-click operate on (at least) selection1.
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.
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.
Thats the only good thing about it... when the X clipboard has an error message in it that I want to search about, I dont need to worry about the search box being already full
When I click the address bar it's because I want to use the current tab to visit a new page, so select-all is perfect.
I think they should make this configurable though, I can see both sides of it.
I think they should make this configurable though, I can see both sides of it.
Click -> select all
Ctrl+Click -> insert
Ctrl+Click -> insert
Ctrl-T and start typing is much faster than mousing the cursor up to the URL bar
I forgot about that use case. I paste into and copy from the address bar all the time. But I still get myself sideways because I treat it like any other text box, and end up de-selecting the URL and having to try again!
You'd think after so long, I'd get used to the behavior and just single-click it. But apparently Pavlov would have me culled from his experiment :)
You'd think after so long, I'd get used to the behavior and just single-click it. But apparently Pavlov would have me culled from his experiment :)
Time doesn't matter, because you probably interacts with many more normal text fields than browsers URL fields. And since they look the same, and act mostly the same, you won't learn to handle it correctly.
Don't forget F6!
Or Crtl+L, for those on 60% keyboards ;)
Alt+D is easier to press with one hand.
That's what I've been telling people! I feel like you're the only other person that knows that shortcut!
Unfortunately, Alt+D is also sometimes overridden by JS applications. This is especially annoying in Google Sheets.
Ctrl+L will still work.
Unfortunately, Alt+D is also sometimes overridden by JS applications. This is especially annoying in Google Sheets.
Ctrl+L will still work.
I've never noticed or been bothered by this. Typically when I want to edit a URL it's almost always deleting or replacing a substring in the URL. To do that I just single click + drag which highlights only the selected text instead of everything.
Sounds like it should be user configurable, because I agree with you that selecting the whole thing by default is annoying.
Unfortunately user-configurability seems to be a out of fashion these days.
Firefox, despite the impression that HN might give, is still very configurable. The existence of about:config means Mozilla can add options without cluttering the more accessible preferences menu. I'm perfectly happy with the default behavior of selecting everything by default, but it does seem like the sort of thing that would be nice to make configurable by those who are willing to mess with about:config.
The linked bug report is literally that one of the about:config preferences has been removed and will no longer be respected.
It adds a lot of complexity and therefore cost unless you don't care about testing.
It used to be. It was for awhile the very first thing I'd change in the Firefox config.
When they added the omnibar they just ripped out the feature flag because reasons.
When they added the omnibar they just ripped out the feature flag because reasons.
This is pretty much why I don't use Firefox. Things like this are a deal breaker for me. I really wanted to use that browser, so I even tried at some point fix it myself.
Their behaviour makes Firefox match other browsers - Firefox doesn't need to be different for the sake of it.
It's more complicated than how you're presenting it.
The comments on the bug report point out that the new behavior makes Firefox on Linux different from other Linux applications, including some browsers. The devs said they want Firefox to be consistent across platforms, whereas the Linux users want Firefox to be consistent with the rest of their system.
The new behavior is also different from the behavior of text boxes rendered by Firefox.
The comments on the bug report point out that the new behavior makes Firefox on Linux different from other Linux applications, including some browsers. The devs said they want Firefox to be consistent across platforms, whereas the Linux users want Firefox to be consistent with the rest of their system.
The new behavior is also different from the behavior of text boxes rendered by Firefox.
Their behavior makes Firefox unlike literally every single other program with a text box, except the singular other browser people actually use. Neither browser should be different for the sake of it.
Sorry not sure what you mean? This is exactly how Safari, Chrome, and I guess others I can't immediately test work. Seems good to work as expected from other browsers?
They're saying, I think, that the textbox which is a URL is a special textbox but it shouldn't be. It should be the same as any other textbox in Firefox.
^the same as any text box on any OS since Mac Classic and perhaps before on the Xerox.
> It should be the same as any other textbox in Firefox
Editing strings in `about:config` seems to behave identical to the URL bar, and Ctrl+F behaviour is similar (but other search bars, like in settings, do not highlight all). Possibly more, just did a quick check of the text boxes I remember Firefox's UI having.
Editing strings in `about:config` seems to behave identical to the URL bar, and Ctrl+F behaviour is similar (but other search bars, like in settings, do not highlight all). Possibly more, just did a quick check of the text boxes I remember Firefox's UI having.
Yeah, and that's cool. I get being consistent with other browsers. I also miss being able to invert the choice with an about:config toggle.
I also know that I'm in the minority, and that maybe the size of my cohort is too small to add yet another thing to check during regression testing.
But I'm still mad about it :) Firefox always seemed like the browser for people who want to configure weird things, or extend it in all sorts of crazy ways. More and more it's becoming a me-too browser, and the only reason I'm sticking with it is out of a sense of duty to fight a Chrome monoculture.
I also know that I'm in the minority, and that maybe the size of my cohort is too small to add yet another thing to check during regression testing.
But I'm still mad about it :) Firefox always seemed like the browser for people who want to configure weird things, or extend it in all sorts of crazy ways. More and more it's becoming a me-too browser, and the only reason I'm sticking with it is out of a sense of duty to fight a Chrome monoculture.
Yeah they can't really win - do they try to keep happy a dwindling group who liked Firefox the way it was in the past, or simplify and streamline to innovate more quickly appeal to new users. It's probably impossible to do both. I'm firmly in the anti-customisation camp myself. They obviously aren't ever going to appeal to both of us.
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.
> 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 ;-)
It doesn't need to be the same for the sake of it either.
Most of the times when I interact with the address bar it's either to go to a different site, google something or copy the url - in all of those use cases I interact with the entire address to either replace it or select it.
I would wager almost anything that this is the case for the vast majority of regular users because most of the ones I've interviewed (N = 31) for a uni UX study didn't even know how to read URLs for the most part - especially not after the ? query part.
I would wager almost anything that this is the case for the vast majority of regular users because most of the ones I've interviewed (N = 31) for a uni UX study didn't even know how to read URLs for the most part - especially not after the ? query part.
It's sad but true. Googling is probably Firefox's only feature left. After they trashed the dev ecosystem, removed file access, prevented 127. access and prevented ssl bypass for 10. and 192.168. broke markdown rendering, disabled CD access, made development painful, fsckd ftp, banned useful stuff on file:// removed anything useful from about: made developing inside Firefox a nonstarter, borked Web app, and generally broke any use case other than Googling/Shopping.
I doubt many people type much into the omnibar other than input for advertising platforms.
They should probably replace
http://
with
today I want to buy...
I doubt many people type much into the omnibar other than input for advertising platforms.
They should probably replace
http://
with
today I want to buy...
Firefox 55 has all of those features! I just never updated.
Sure, these extensions and workarounds are dangerous and inconvenient, but I do love well behaved web browsers.
Sure, these extensions and workarounds are dangerous and inconvenient, but I do love well behaved web browsers.
Wow! Consider moving to Pale Moon at least, it will work with more sites and gets security patches.
What a load of bollocks and incredibly sad way of looking at things.
Huh, funny. I think I notice this on my phone. But on my desktop it's always Ctrl-L so I never realized.
Or Ctrl-l (which I assume is Cmd-l on your platform).
most of the time if I click there it's to copy/paste it somewhere else, and I'm pretty sure most people use it the same way.
> 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 before I begin typing.
I'm with you on this. But to me the worst annoyance is how it tends to revert to a previous URL when the new URL fails to load, either because it truly failed to load due to an error or because it timed out while I'm walking through breakpoints.
When I manually entered a URL, the edit should stick even if it doesn't load, dammit.
I'm with you on this. But to me the worst annoyance is how it tends to revert to a previous URL when the new URL fails to load, either because it truly failed to load due to an error or because it timed out while I'm walking through breakpoints.
When I manually entered a URL, the edit should stick even if it doesn't load, dammit.
Even if you disagree with the reason might as well give the devs’ stance on it.
> it [single clicking not selecting all] was a special behavior only implemented for Linux, it was not consistent with Firefox on other OSes, and with other browsers on Linux itself. The prefs were causing broken edge cases complicate to handle, taking into account all the possible pref combinations (for example under certain combinations it was not possible to select a word), and having to execute more tests for them. Not removing the prefs would have not saved many resources, since we still need to maintain them.
Why can’t you just have both options?
> Most of the tests should then be able to run with both setups, everytime we touch something around that we'll have to check not breaking it, and so on. Yes, even the simplest pref skipping a line has a cost, and that's why they must be weighted with a benefit.
> Apart from what I already said regarding the will to unify the behavior for the more commonly found case of users moving across OS and browsers, and the cost of options in general, I'd like to explain a further reason why it's not just matter of reintroducing a pref; the change we made here will allows us to experiment more broadly with the unfocused Address Bar contents, for both UX and security reasons. Keeping browser.urlbar.clickSelectsAll around would make experiments a lot more problematic, and at a certain point we may have to remove the pref regardless, because it would block landing improvements. So we'd end up causing you frustration twice. We totally understand your point of view on this matter, unfortunately sometimes changes must happen, to be able to evolve things.
> it [single clicking not selecting all] was a special behavior only implemented for Linux, it was not consistent with Firefox on other OSes, and with other browsers on Linux itself. The prefs were causing broken edge cases complicate to handle, taking into account all the possible pref combinations (for example under certain combinations it was not possible to select a word), and having to execute more tests for them. Not removing the prefs would have not saved many resources, since we still need to maintain them.
Why can’t you just have both options?
> Most of the tests should then be able to run with both setups, everytime we touch something around that we'll have to check not breaking it, and so on. Yes, even the simplest pref skipping a line has a cost, and that's why they must be weighted with a benefit.
> Apart from what I already said regarding the will to unify the behavior for the more commonly found case of users moving across OS and browsers, and the cost of options in general, I'd like to explain a further reason why it's not just matter of reintroducing a pref; the change we made here will allows us to experiment more broadly with the unfocused Address Bar contents, for both UX and security reasons. Keeping browser.urlbar.clickSelectsAll around would make experiments a lot more problematic, and at a certain point we may have to remove the pref regardless, because it would block landing improvements. So we'd end up causing you frustration twice. We totally understand your point of view on this matter, unfortunately sometimes changes must happen, to be able to evolve things.
Wontfixzilla with comments disabled is a clear statement.
Is a wontfix with lots of comments more expensive, than a wontfix with comments blocked?
Shame you cant "give the devs opinion" on bugzilla.
Shame you cant "give the devs opinion" on bugzilla.
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, but by that time we'd already have taken the hit.
These bugs are not fun for anybody, dev or unhappy user alike.
> 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, but by that time we'd already have taken the hit.
These bugs are not fun for anybody, dev or unhappy user alike.
> These bugs are not fun for anybody, dev or unhappy user alike.
Then fix them.
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.
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.
This change was introduced at the same time when google.amp was introduced.
Now both firefox and chrome dont allow you to change the adress easily to manually remove amp.
I wonder if some Firefox developer was bribed
Now both firefox and chrome dont allow you to change the adress easily to manually remove amp.
I wonder if some Firefox developer was bribed
> Now both firefox and chrome dont allow you to change the adress easily to manually remove amp.
I don't see what the single-click functionality has to do with removing something from a URL (as almost all users would perform selection with click-and-drag or a double-click). The primary use case would be for adding text.
I don't see what the single-click functionality has to do with removing something from a URL (as almost all users would perform selection with click-and-drag or a double-click). The primary use case would be for adding text.
This is how it works in all browsers and is useful because more people on average will click the url to remove all the text so they can type something new
UGH the recent Chrome update also adds on top of this if you select then hit left arrow it doesn't even go to start it starts after https:// soooo annoying
I don't remember it doing that before but maybe i have a bad memory
I don't remember it doing that before but maybe i have a bad memory
Huh, just tried that on Chrome/macOS on Reddit and it actually went to the end of the www, no less.
So news.ycombinator.com it goes to the right of https:// and www.reddit.com it goes to the right of https://www.
Madness.
So news.ycombinator.com it goes to the right of https:// and www.reddit.com it goes to the right of https://www.
Madness.
Google's (standardised![1]) destruction of the URL in action.
[1] https://news.ycombinator.com/item?id=20574210
Personally, my preferred way of displaying a URL and interacting with it is a full, unmolested URL, in a regular UI edit control.
[1] https://news.ycombinator.com/item?id=20574210
Personally, my preferred way of displaying a URL and interacting with it is a full, unmolested URL, in a regular UI edit control.
> single click selects all in address bar and search box.
FWIW, this is fixed in Firefox 3.6; you should probably upgrade.
FWIW, this is fixed in Firefox 3.6; you should probably upgrade.
This behavior is the bug. We would prefer the pre-3.6 behavior where the address bar and search box works like a normal textbox.
That is the behavior in 3.6; I'm pointing out that the earlier version (3.6) is a upgrade from the later version (70-something?), because Mozilla is making the browser worse over time.
I use mostly Firefox, but that behavior change didn't trigger me.
However I can relate: When I tried to use chromium I got really annoyed that clicking and dragging the selection with the mouse up or down would not automatically select the complete text in front or behind the cursor in the url bar.
Firefox still allows to do that under Linux. Hopefully they will not change that as well.
However I can relate: When I tried to use chromium I got really annoyed that clicking and dragging the selection with the mouse up or down would not automatically select the complete text in front or behind the cursor in the url bar.
Firefox still allows to do that under Linux. Hopefully they will not change that as well.
Are you a touchpad user? On a PC you get that behavior by simply clicking again, but accurate double clicks are somewhat hard on touchpads, so I get why that'd be annoying.
This may just be laptop/touchpad users complaining, and mouse users not comprehending what the big deal is.
This may just be laptop/touchpad users complaining, and mouse users not comprehending what the big deal is.
Double-click selects the word under the cursor (at least for me on Ubuntu). To get the cursor at the position, it's click-wait-click.
IE, the first browser I started using and still use regularly now alongside others, behaves the same with single-click selecting all in the address bar (and it's NOT configurable AFAIK), so I'm used to that; but I also see the value in making it user-configurable.
Unfortunately, that dumpster-fire of a bug-report/thread is a horrible abomination that shows massive hubris on the part of the developers; and I say this as a developer myself --- and one who fights against this sort of thing far too often to count. Change the defaults if you really want, but never remove the choice.
(The argument that it has "costs" is stupid --- yes, everything has costs, but they actually have perceived value in this case, unlike working on something else, often of much greater complexity and cost, that your users never even asked for in the first place!)
Unfortunately, that dumpster-fire of a bug-report/thread is a horrible abomination that shows massive hubris on the part of the developers; and I say this as a developer myself --- and one who fights against this sort of thing far too often to count. Change the defaults if you really want, but never remove the choice.
(The argument that it has "costs" is stupid --- yes, everything has costs, but they actually have perceived value in this case, unlike working on something else, often of much greater complexity and cost, that your users never even asked for in the first place!)
Interesting, I've always loved this feature. I guess in my use cases, whenever I go to click the URL bar I'm intending to copy/paste it more often than edit. Either way, it's deeply ingrained into my muscle memory by now to go click -> pause -> click to edit.
Ctrl+L/F6 already supports that use case and more quickly since you'll need to paste or edit.
Yup, same here. I get that some people don't like it, but it's making a mountain out of a mole-hill. I bet that if you do user studies, you will find that a majority of times people click in the URL bar, they are doing so to either copy the entire URL or paste in a new URL. I know I am and I much prefer the current behavior.
A variation on this - Chrome also select the whole address bar, but if you then click a fraction of a second later hoping to position the cursor where you clicked, you find that the https:// appears at the beginning, meaning your cursor is several characters to the left of the position you were hoping for.
Agreed! I find this infuriating. To fix it there’s a flag for “always show full URL”, which I’ve turned on. Fixes it completely.
There may be a flag to "always show full URL"; if it isn't available (in the address bar context menu) you need to go to chrome://flags/, enable the "Context menu show full URLs" option, restart Chrome, and then enable the option.
Using the shortcut CMD+L (changes focus to and selects the whole url) Makes this a non issue personally, your mileage may vary
Fortunately it can still be reverted if you are willing to compile FF yourself. I've been using Firefox Nightly for a few years (newer features + unsigned addons, and very stable) and recompile it every few weeks to update.
https://the-pwner224.neocities.org/compiling-firefox/
https://the-pwner224.neocities.org/compiling-firefox/
Thank you for these instructions! I've got a patched version compiling right now.
> https://bugzilla.mozilla.org/buglist.cgi?votes=133
No longer shows up here, because it's now 135 votes.
No longer shows up here, because it's now 135 votes.
If you click+drag or double-click to select the substring of the URL you plan to edit anyways, then the click won't select all the URL.
Hum there is a setting to change that behavior
Agree with the sentiment in those bug report threads.
The one that grinds my gears is that when you select the URL bar in Chrome it shifts the whole thing to the right, so if you want to edit text you have to reposition the cursor, you can’t just click, pause, then click again.
The one that grinds my gears is that when you select the URL bar in Chrome it shifts the whole thing to the right, so if you want to edit text you have to reposition the cursor, you can’t just click, pause, then click again.
[deleted]
Agreed, maddening. I kept my Firefox installation pinned to 74 for as long as I could because of this, but I had to give in and update to 85 a couple of weeks ago for something. I scan the release notes for each release in hope, but no.
I don't really care about consistency with other browsers - I don't use other browsers very much. I care about consistency with everything else on my desktop.
(It's not just about the option - I didn't even use the browser.urlbar.clickSelectsAll option myself. The clickSelectsAll=false behaviour - the one that was removed - had been the default on Linux.)
I don't really care about consistency with other browsers - I don't use other browsers very much. I care about consistency with everything else on my desktop.
(It's not just about the option - I didn't even use the browser.urlbar.clickSelectsAll option myself. The clickSelectsAll=false behaviour - the one that was removed - had been the default on Linux.)
It’s also interesting that the context of this bug has changed over the years. I’d be surprised to learn if we had gigantic single-page api reference docs 17 years ago
On the other hand the tutorials I remember following back in the days were quite long and all in one page, while today those tend to be split into annoyingly many pages.
For more ad serves. F the modern web.
Nah, docs in general are just very big these days, it makes quite a bit of sense to not load all of them into one single page. I do like that I can search all of pandoc's documentation with just Ctrl+F, but that's not reasonable for all software. Heck, even man pages are split up into many pages for more complex tools.
I'm immensely grateful to the developers involved. I'm sure it wasn't easy but it's one of those features that I've always missed ever since chrome added it.
It also shows the value of a decent bug tracking system.
Does anyone know were we can find a screenshot of this new feature in action?
Glad they finally add this. Used to be a painful lack compared to chromium-based browsers. During the long wait I've found this amazing addon called HighlightAll [1], which allows you to search multiple keywords and highlight them with different colors; the position will also be labelled on the scroll bar. Super helpful for researching/consuming long articles.
[1]: http://jgoudey.free.fr/highlightall/
[1]: http://jgoudey.free.fr/highlightall/
This was a feature that appeared in chrome way back when and was what made me switch. Always felt Firefox search was inferior because this was missing.
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.
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.
Fantastic. There's hope. (Greed incoming beware). What about WebMIDI support for music web apps like Pianojacq?
Obligatory dogpile, but I'm hoping for the day you can disable Ctrl-Q to prevent accidentally closing the browser with a single keystroke. It's impossible to do on Linux.
Yeah Chrome's "hold to quit" feature is genius. I wish VSCode had it too.
Uggh. I pretty much never use Chrome on my Mac, but when I borrow someone else's computer and want to quit Chrome I always get bit by this one! No other application have I seen that makes you hold down ⌘Q to quit, except for Chrome. This is not conventional on Mac apps! It's probably configurable but why make it the default?
Because nobody would know it even existed if it wasn't the default and it's a great feature!
You can hack it in VSCode by turning on the warn-before-terminal-closed feature, and making the terminal always load.
Only drawback (maybe) is that every open project in VSCode warns when trying to close the entire app.
Only drawback (maybe) is that every open project in VSCode warns when trying to close the entire app.
[deleted]
I'm on mac, but I used to have the same problem also in other apps: I use a system wide app that makes you long press cmd-Q to quit any app (with an allow/block list): "SlowQuitApp". Just in case you never thought to try to find something similar (assuming ctrl-q is a common shortcut in linux, I forgot)
I did actually use this when I used macOS, but when I moved to Linux there was apparently no equivalent at the time.
https://superuser.com/questions/1318336/how-to-disable-ctrlq...
https://superuser.com/questions/1318336/how-to-disable-ctrlq...
On Fedora Chrome disables Ctrl+Q and Chrome can only be closed by going through the menu. Maybe Chromium implements it too, then you could find out the trick in the source.
That has bit me so many times. Especially since Q is right next to W. Trying to close a tab with Ctrl-W and accidentally hit Q :(
It's partially fixed now, it'll show the "Quit and Close Tabs" dialogue now if you check "Warn you when quitting the browser" in the preferences.
IMO this should be a feature of the window-manager, not the application. But that requires a change in the interface between window-managers and applications, to allow the window-managers to be more heavy-handed. Which I've wanted for a very long time.
Funny enough, that's basically the direction both Mac OS and Windows take things. On Linux, X11 is the norm and window managers do very little other than add decoration around a rectangle.
Wayland probably providers tighter coupling, but then you'll need cooperation with applications... GNOME has gone toward this direction, but applications not developed by GNOME basically ignore their efforts to make applications and window manager feel like a cohesive whole.
Wayland probably providers tighter coupling, but then you'll need cooperation with applications... GNOME has gone toward this direction, but applications not developed by GNOME basically ignore their efforts to make applications and window manager feel like a cohesive whole.
Good timing! I actually fixed this 21 year old feature request: https://bugzilla.mozilla.org/show_bug.cgi?id=52821
You can set browser.quitShortcut.disabled=true in about config starting with Firefox 87.
You can set browser.quitShortcut.disabled=true in about config starting with Firefox 87.
Whoa, that is incredible, thank you SO MUCH! <3
I don't think I can explain the extent to which this simple papercut has been vicious and painful to me.
So many times, I've started writing some long post in a text field and accidentally lost it due to pressing some wrong keyboard shortcut (oops, you pressed backspace outside a text field! oops, we bound this key to 'reload the page', oops you closed the form by pressing ESC!). It's always a particular type of sinking feeling to have to start writing all over again.
Now there are extensions for this, and some of them even work. But what's my natural instinct when I have data in a text field I really don't want to lose because I would feel terrible losing it?
Well, ^A ^C and go paste it in a notepad, maybe even finish editing it there.
... and then Firefox quits, maybe because my layout switched between AZERTY and QWERTY by accident, maybe because my finger slipped between A and Q. And I get to stare at my desktop, crushed and defeated, having lost my data at the exact worst possible time...
I was seriously starting to consider maintaining my own Firefox fork, and I _cannot thank you enough_!
I don't think I can explain the extent to which this simple papercut has been vicious and painful to me.
So many times, I've started writing some long post in a text field and accidentally lost it due to pressing some wrong keyboard shortcut (oops, you pressed backspace outside a text field! oops, we bound this key to 'reload the page', oops you closed the form by pressing ESC!). It's always a particular type of sinking feeling to have to start writing all over again.
Now there are extensions for this, and some of them even work. But what's my natural instinct when I have data in a text field I really don't want to lose because I would feel terrible losing it?
Well, ^A ^C and go paste it in a notepad, maybe even finish editing it there.
... and then Firefox quits, maybe because my layout switched between AZERTY and QWERTY by accident, maybe because my finger slipped between A and Q. And I get to stare at my desktop, crushed and defeated, having lost my data at the exact worst possible time...
I was seriously starting to consider maintaining my own Firefox fork, and I _cannot thank you enough_!
Fixing the Ctrl+Q issue is great, but I still think extensions such as Form History Control are essential for all other situations. I'd very much appreciate if Mozilla could vet it for security; I'm always afraid of some developer selling out or being hacked and a future update introducing a backdoor.
> So many times, I've started writing some long post in a text field and accidentally lost it due to pressing some wrong keyboard shortcut (oops, you pressed backspace outside a text field! oops, we bound this key to 'reload the page', oops you closed the form by pressing ESC!).
For me it's often ctrl+w to delete one word, which terminals have gotten me used to. I don't want the shortcut removed because I use it all the time to close tabs outside a text box, but it also still working while focused in one is annoying.
For me it's often ctrl+w to delete one word, which terminals have gotten me used to. I don't want the shortcut removed because I use it all the time to close tabs outside a text box, but it also still working while focused in one is annoying.
Oh god yes, backspace outside the text box is the worst. Some websites mitigate this themselves, but it would really be nice if the browser could take care of this.
Firefox already lets you disable that using the browser.backspace_action setting in about:config: https://support.mozilla.org/en-US/questions/924490
Not a bug I personally was very affected by, but:
Thank you so much fpr actually fixing bugs!
If my impression of Mozilla is correct you must have both done the work and possibly also fought hard to be allowed to merge it.
(Now, if any Mozillan feel inspired I'd love to get my real extensions back, particularly TST without top tab bar and also Scrapbook.)
Thank you so much fpr actually fixing bugs!
If my impression of Mozilla is correct you must have both done the work and possibly also fought hard to be allowed to merge it.
(Now, if any Mozillan feel inspired I'd love to get my real extensions back, particularly TST without top tab bar and also Scrapbook.)
I can't find any words to tell you how thankful I am!
My FF is configured to delete all history upon exit, so I have lost SO MANY interesting browsing sessions over the years due to CTRL+Q!
Thank you very much for finally resolving this!
My FF is configured to delete all history upon exit, so I have lost SO MANY interesting browsing sessions over the years due to CTRL+Q!
Thank you very much for finally resolving this!
Much appreciated! Figures that it was a 21-year-old bug. I'm wondering why it took so long, but regardless, you're my savior.
Coincidentally, when Mozilla's blog post about shipping a big cookie separation feature was on the front page recently, the first thing I thought was "but when will they let you disable CTRL+Q? It'd be so much easier to do than this." In the age of Chromium, issues like this will lead to death by a thousand cuts for Firefox. The cost of switching is marginal for most people, as Chrome has become too well-architected as a browser which ends up connecting you to Google. I myself was almost tempted to switch because of this and other relatively minor issues that ended up snowballing together, and I'm a person that makes a deliberate effort to like Firefox. I have to wonder why nothing changed in 2002, when so many people were making so much noise about this.
Coincidentally, when Mozilla's blog post about shipping a big cookie separation feature was on the front page recently, the first thing I thought was "but when will they let you disable CTRL+Q? It'd be so much easier to do than this." In the age of Chromium, issues like this will lead to death by a thousand cuts for Firefox. The cost of switching is marginal for most people, as Chrome has become too well-architected as a browser which ends up connecting you to Google. I myself was almost tempted to switch because of this and other relatively minor issues that ended up snowballing together, and I'm a person that makes a deliberate effort to like Firefox. I have to wonder why nothing changed in 2002, when so many people were making so much noise about this.
oh wow!! that's amazing, i've been waiting for this one forever.
Awesome, thank you. This will fix most of my accidental firefox closing. Too bad that I sometimes fatfinger ctrl-w as ctrl-shift-w.
I'm not sure if it's an option in the settings now or not but if you go to `about:config` in firefox and search for `browser.warnOnQuit` you can make sure that's set to `true`.
Another favorite of mine: `browser.tabs.closeWindowWithLastTab` set to `false`. This lets me cmd-w as many times as i want but it won't close the window I have open.
Another favorite of mine: `browser.tabs.closeWindowWithLastTab` set to `false`. This lets me cmd-w as many times as i want but it won't close the window I have open.
I was a Firefox user from the Phoenix/Firebird days and I keep trying to make it my primary browser again and reduce my Chrome usage to fight the monoculture. I am probably about 50/50 between them. One of the few Chrome plugins I use is QuickTabs and I it is bound on ctrl-q ofcourse. That works out about as well as you would expect.
Firefox is still a fantastic browser but it can be frustrating in many small ways.
Firefox is still a fantastic browser but it can be frustrating in many small ways.
For anybody using MacOS, a keyboard customisation program called Karabiner-Elements can help here. By importing a specific KE rule, you can change the behaviour of your keyboard such that a Cmd-Q code is only sent after pressing the key chord twice. IRL this translates into a singular press and hold of Cmd and a double tap of Q and it works on all programs. I can't recall accidentally closing any program since enabling this rule and it takes next to no extra effort to work with it enabled.
https://bugzilla.mozilla.org/show_bug.cgi?id=915
It is older!
It is older!
That was a WONTFIX, not FIXED.
Try reading carefully.
It's we don't know how to fix and just wait until it will disappear.
I read it just fine. Thanks for your concern though.
17 years is pretty good. I had BSD gnats bugs 10+, which I would have loved to be fixed, but the BIOS in question (it was ACPI stuff) is long dead. However, similar bugs persist in modern hardware/software "layer 2" systems under the OS. They're just hard to fix, without NDA.
The entire 802.11 blobs story, is about persisting "if we knew how the magic FPGA works we'd fix this" stories.
The entire 802.11 blobs story, is about persisting "if we knew how the magic FPGA works we'd fix this" stories.
Comment 6 • 15 years ago :
> I'm going to take this bug so maybe someday I can do it. Way too hard for now, but it would be very nice to have.
Now that's persistence!
> I'm going to take this bug so maybe someday I can do it. Way too hard for now, but it would be very nice to have.
Now that's persistence!
I'd look for a ticket about the poor contrast of matches, either green or magenta.
Still sad that https://bugzilla.mozilla.org/show_bug.cgi?id=14328 was closed 2 years ago after being open for 20 years.
I just love how the first comment is about how IDEA has this feature.
[deleted]
Of course, there used to be an add-on that added this functionality, but was subsequently killed by the 57 update.
I wonder what Keith Lea is up to these days. Someone should let him know this is implemented!
See! You just had to be patient!
Great, now maybe they can fix the size of adding bookmarks window.
https://bugzilla.mozilla.org/show_bug.cgi?id=219972
My favorite bug, 18 years old, closed without replacement.
https://bugzilla.mozilla.org/show_bug.cgi?id=219972
My favorite bug, 18 years old, closed without replacement.
The bug you linked is about the properties window of an existing bookmark, which is resizable.
I might have linked the wrong one, it doesn't change the fact that the window still isn't resizable and there is a bug of similar age buried in bugzilla.
Wow, finally
Good. Can we have webmidi next?
Don't we already? I thought I used that before.
Not on FF in the standard config. Chrome yes. Webaudio does work, maybe that confused you?
Hopefully not. The less surface area browsers expose the better.
I've got just the thing for you:
https://en.wikipedia.org/wiki/Lynx_(web_browser)
https://en.wikipedia.org/wiki/Lynx_(web_browser)
That's what I love about FOSS!
If a program doesn't have the feature you like, it can always be added -- 17 years later.
If a program doesn't have the feature you like, it can always be added -- 17 years later.
I love this about the internet in general. It could have been possible for the person that implemented the change to be born after the request was even made. All the while the discussion thread was maintained alive, while that person would be going to school and learn to code.
Similarly you can post a very specific question on a forum and it's possible the person that will answer it casually many years later as if they were just continuing the discussion wasn't even born when you posted the question.
These extremely asynchronous interactions between strangers are something unique. I wonder what's the current record for longest lived discussion thread like this, or the question-answer pair with the longest interval. A bit like the open-ended questions in academia that are answered decades later.
Similarly you can post a very specific question on a forum and it's possible the person that will answer it casually many years later as if they were just continuing the discussion wasn't even born when you posted the question.
These extremely asynchronous interactions between strangers are something unique. I wonder what's the current record for longest lived discussion thread like this, or the question-answer pair with the longest interval. A bit like the open-ended questions in academia that are answered decades later.
[deleted]
so still not the fix for tree style tabs...
there is always hope
I am never really sure how this feature is helpful, I don't know if I'm being obtuse about the functionality that people give it.
In the JetBrains software I use it all the time but only cause it's clickable.
In the JetBrains software I use it all the time but only cause it's clickable.
Cool, at that rate only another 16 years or so until they'll fix the fact that running a Zoom or Hangout call on Firefox turns your MBP into a toaster.
Wish they'd focus on battery use! It's so crazy un-optimized. Run your next Zoom call on Firefox and put your laptop on your lap to test... Or just watch the battery meter plummet vs. other browsers.
Wish they'd focus on battery use! It's so crazy un-optimized. Run your next Zoom call on Firefox and put your laptop on your lap to test... Or just watch the battery meter plummet vs. other browsers.
On another note, the comment uses IntelliJ as an example. Wow, that was 17 years ago! Happy to see my favorite editor be around for so long.