17 year old Firefox feature request fixed

Wait is Emacs lying about its age again?

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.

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 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 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 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.

Trying to cry in eclipse editor, but its not responding :(

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.

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.

Please remove the link.

oh, I love jwz's HN DoS mitigation image.

Did anybody ever find the secret?

Take a look at the root pages html source

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.

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.

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.

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.

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.)

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.

There's no way Mozilla is going to rewrite their entire UI layer for a single OS, much less a minority one.

Making it also respect dark mode in alerts would be nice.

This makes me very happy. It sounds dumb but I've considered switching from Firefox just because of the context menus.

Also, why is there a jira.mozilla.com at all, and why is there a jira.mozilla.COM?

Now that’s a name I’ve not heard in a long time.

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 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

"Because not many people use it" was the excuse Google gave for killing RSS.

I certainly don't use it since it's gone, I have to save pdf on desktop and then rsync it to the phone.

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.

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.

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.

Don't forget F6!

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.

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.

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.

Huh, funny. I think I notice this on my phone. But on my desktop it's always Ctrl-L so I never realized.

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.

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.

> 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.

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.

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.

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.

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.

Ctrl+L/F6 already supports that use case and more quickly since you'll need to paste or edit.

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.

Thank you for these instructions! I've got a patched version compiling right now.

Not anymore ;) https://bugzilla.mozilla.org/buglist.cgi?votes=136&list_id=1...

For more ad serves. F the modern web.

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.

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?

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...

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.

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!

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.

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_!

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.

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.)

Try reading carefully. It's we don't know how to fix and just wait until it will disappear.

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.

Not on FF in the standard config. Chrome yes. Webaudio does work, maybe that confused you?

I've got just the thing for you:

https://en.wikipedia.org/wiki/Lynx_(web_browser)