If you're like me, and read the comments first, this change is about giving feedback on the scrollbar for a search. In other words, when you search for something, the scrollbar will give an idea how many results there are, and where on the page rhey are located.
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.
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.
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.
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?
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.
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.
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.
Absolutely. I severely dislike the "bug scrub" attitude that's prevalent in some places that amounts to just closing anything that is not P1 and older than some short time window.
The idea of a bug tracker is to track bugs in the product. If the bug still exists in the code, the bug in the tracker should still be open.
The counterargument is that a bug is enough a function of its context that the older they get, the less likely they are to still be relevant or accurately documented. Having a bug on the list isn't enough - it needs to be periodically reviewed, kept up to date, prioritized, etc.
Sometimes the overhead of that maintenance work isn't worth it, particularly for a bug that's been explicitly categorized as 'low priority' for years. The fact that a bug can stay at low priority for years is a reasonable sign that it's not too important to spend a lot of effort either tracking it or fixing it.
With that point of view, closing the defect as unfixed and explaining the reasons why is in some ways more honest than just keeping the thing open ad infinitum just because somebody, at some point in the past, thought there was an issue. And if closing it was wrong, you'll run into the issue again, and can either re-open the defect or submit a new defect with a back link to the original, and an explanation of what's changed that's brought it back into relevance.
(Personally speaking in the last few months, I've gotten several good solutions from reading the commentary on defects that were closed as unfixed.)
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.
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.
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 :)
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 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):
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.
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.
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 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.
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.
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.
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.
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 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.
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.
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'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.
> 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.
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.
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.
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!)
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.
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.
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.
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.
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.
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 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.
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.)
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.
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.
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
> 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.
Readit News
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.
"Nearly half my age," said Emacs.
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.
What do you think is the biggest difference between the two?
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.
Looking at you, every random GitHub project ever.
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.
(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.
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.
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.)
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.
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.
We're on our 3rd or 4th now.
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?
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
Take a look at the root pages html source
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.
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'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.
https://bugzilla.mozilla.org/show_bug.cgi?id=505089http://forums.mozillazine.org/viewtopic.php?p=7018785
https://bugzilla.mozilla.org/show_bug.cgi?id=34572
https://bugzilla.mozilla.org/show_bug.cgi?id=868370
[1] https://ibb.co/0hRpSBB [2] https://ibb.co/wwhCypT
This is likely a separate ticket, but Firefox ignores macOS' built-in text replace which I use for expanding text like my email address.
Deleted Comment
https://bugzilla.mozilla.org/show_bug.cgi?id=259640
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=1621570https://bugzilla.mozilla.org/buglist.cgi?votes=133
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 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'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.
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.
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!)
https://the-pwner224.neocities.org/compiling-firefox/
> 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.
Shame you cant "give the devs opinion" on bugzilla.
I don't remember it doing that before but maybe i have a bad memory
So news.ycombinator.com it goes to the right of https:// and www.reddit.com it goes to the right of https://www.
Madness.
FWIW, this is fixed in Firefox 3.6; you should probably upgrade.
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.
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.)
This may just be laptop/touchpad users complaining, and mouse users not comprehending what the big deal is.
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.
No longer shows up here, because it's now 135 votes.
Deleted Comment
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
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.