If you're curious about how you'd even go about finding and fixing a bug in the Firefox codebase, Mike Conley has been livestreaming his dev work at Mozilla weekly for <i>years</i>. A lot of the stuff he records involves picking a bug from the backlog, and then meticulously hunting it down and murdering it.<p>I really recommend giving it a watch, especially if you're just starting out in programming and want to see what work in a real codebase is like: <a href="https://youtube.com/@mikeconleytoronto">https://youtube.com/@mikeconleytoronto</a>
At last. More of this please, Mozilla...<p>One of the most annoying versions of this bug is when launching a full screen game, the mouse gets re-positioned and triggers a tooltip, which is on top of the game, and the game doesn't like alt-tabbing when you unfocus it to go deal with Firefox, so you just have to restart it...
I have always blamed my various linux desktop window managers for that bug, never realizing its always the same culprit :facepalm:<p>On occasion (a smaller screen) it could be quite annoying as it might interfere with the display of a form or other critical element.<p>Looking forward to the update and the next 22 years of firefox not just being bugfree but being the impactful application it once was.
<a href="https://phabricator.services.mozilla.com/rMOZILLACENTRAL8ae372dc88d1d1b1b5fd4783aec003da378c3e45" rel="nofollow noreferrer">https://phabricator.services.mozilla.com/rMOZILLACENTRAL8ae3...</a><p>If you see the five line fix for the bug and think "I could have done this!" You could!<p>The actual answer is "why didn't't I?"<p>So to answer that question for myself : How easy is it to compile Firefox and run the test suite?<p>The long bug hunting bit after that is the fun part.
Oh wow, I always just assumed it was somehow my fault. This has been following me for years, over different Windows versions and reinstalls. It didn’t happen often, but still regularly enough that I remember it.
Quite a curious bug that many people seem to have come across, some mention that they encounter it at least once a day, and yet I don't think I've seen this behaviour even once in the last decade and a half. It doesn't seem limited by OS either, so I wonder what the actual conditions for the bug to manifest itself were.<p>(The only place I come across a similar bug is with LibreWolf (a customized privacy-enhanced Firefox). And I'm pretty sure that has to do with the fact that it's a flatpak, rather than to do with the browser itself, since no other Firefoxes I run have ever exhibited this behaviour.)
Interesting, this bug was filed before even the first version of Firefox was ever released -- <a href="https://en.wikipedia.org/wiki/Firefox_early_version_history" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Firefox_early_version_history</a>. Impressed that they've kept the bug tracker history working for so long.
Oh god, finally. A related bug, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1569439" rel="nofollow noreferrer">https://bugzilla.mozilla.org/show_bug.cgi?id=1569439</a> , was closed 9 months ago, and that made things <i>slightly</i> better (that one is about tooltips not disappearing when simply switching to another app), but I was incredibly disappointed to find that they'd still stay up when switching to another workspace.<p>On the downside, this is sorta a "wrong" fix. Tooltips <i>should</i> show up even if the window doesn't have focus (at least on Linux with GTK apps, which Firefox attempts to emulate). They should fix the actual underlying issue of them not disappearing when the mouse pointer isn't actually over the window anymore, when workspaces change.
Direct link to patch: <a href="https://hg.mozilla.org/mozilla-central/rev/8ae372dc88d1" rel="nofollow noreferrer">https://hg.mozilla.org/mozilla-central/rev/8ae372dc88d1</a>
Meh, 22 years? That's not even close to the longest standing bug I know of that's been fixed. ;)<p>Here's the story of a 33 year old bug in yacc that was fixed in 2008: <a href="https://undeadly.org/cgi?action=article&sid=20080708155228" rel="nofollow noreferrer">https://undeadly.org/cgi?action=article&sid=20080708155228</a>
I like making fun of them for not fixing decades-old bugs (and there's still a considerable amount left) and didn't really have hope they'd <i>ever</i> care.<p>What beautiful news if this indicates that some other old bugs will eventually be fixed as well!
Oh. I'm affected, seeing it several times a day, but I never managed to reproduce 100%. Didn't bother me too much but I guess I could happily do without.<p>It also affects Thunderbird.<p>I had no idea it was a well known, 22 year old bug.
A couple years ago I was Googling myself and found to my surprise a bug I had opened for Mozilla on BeOS in roughly the year 2000 was still open. Searching their Bugzilla now, I find no references to BeOS at all, were their issues pruned at some point?
This is probably quite a common phenomenon in open source software. Namely, an unglamorous bug has been around forever and someone finally gets annoyed enough to roll up their sleeves and fix it themselves.
Apparently it's fixed in FF119. I'm on 102esr under Linux, but I can't replicate.<p>[Edit] OIC, it's a heisenbug. Funny though; I'm a longtime FF user, and I don't recall witnessing it.
Ugh, that sucks. I've been relying on this bug to create persistent sticky notes on my screen. Why do browsers insist on breaking stuff?<p><a href="https://xkcd.com/1172/" rel="nofollow noreferrer">https://xkcd.com/1172/</a>
Tooltips are the worst kind of information providers in a website. First of all you don't know they're there, you actively need to search with your mouse cursor and wait to see something lights up. And then you can only read it, no way to copy/paste information out of it. Often they also cover up other information when they do popup, and most of the time the extra information they do provide is useless.<p>Tooltips should be removed entirely instead of fixing 22 year old bugs.
Firefox is just going to die from bureaucracy. I have another bug report on middle click drag scrolling that took them years to acknowledge and remain unresolved.
I'm hoping they fix that "you shall enter your credentials manager password or we will bug you for it on every. single. page with login form" (which on some webpages is literally every page). It forces one to be logged into password manager all the time, instead of authenticating just when needed.<p>Still, I trust Mozilla more than some random xyzPass.
Hey Dang, isn’t this post breaking the guidelines? The post is not using the original title:<p>> <i>148624 - (tooltip-ghost) Tooltips persist in foreground when Firefox is in background</i><p>My point here is a meta point: it’s great that we can change the titles to something more descriptive.
Does anyone have a link to the commit that fixed the bug? I'm curious how simple it was to fix<p>Edit: nvm, I found the link in the linked page: <a href="https://hg.mozilla.org/mozilla-central/rev/8ae372dc88d1" rel="nofollow noreferrer">https://hg.mozilla.org/mozilla-central/rev/8ae372dc88d1</a>
Wow, this brings back memories. Years ago, the persistence of this particular bug led me to believe that Firefox was "buggy" and "messy". It broke any perception in my mind that Firefox is an elegant tool. It hit whatever that cognitive bias is [cit needed] that tells us "if it can't get simple things right, what else is it getting wrong?" or perhaps "beauty good / ugly bad".<p>I'm older now and have Experience(TM). I know that:
a) many expensive commercial tools are far less elegant and just plain broken (looking at you Autodesk AutoCAD and Revit since 2010s)
b) my own idiocy/ignorance has larger-than-expected extents<p>I wonder if I'm just jaded. Is it correct to believe that Firefox is "good" software? Is it what it is designed to be?
So, there is hope that in 10 years this bug in LibreOffice is fixed :(
<a href="https://bugs.documentfoundation.org/show_bug.cgi?id=46429" rel="nofollow noreferrer">https://bugs.documentfoundation.org/show_bug.cgi?id=46429</a>
I've just been trying to think how long the most annoying Firefox issue I see every day has been around, it's at least 10 years and it's very disruptive - copying just will, 70% of the time, not actually copy (mostly when copying URLs, as in right click, copy link context option, but happens on other occasions too even when using ^x)<p>I can't be the only one suffering this, because no other application does it, although thunderbird has done on occasion but that is hardly the worst thing about it..<p>And then there is Firefox on Android, some genius decided to disable pull down refresh by default, not a bug I guess but more annoying than the plethora of problems.
Could this be the same tooltip issue I see everyday on Thunderbird? I must use Firefox differently but in Thunderbird I'm often left with a tooltip telling the date of the last message I was looking at after changing to a different app.
One recent bug I've seen with tooltips is on wayland... it causes the whole display window to flicker between the current renderer and what appears to be an old back buffer... hopefully it doesn't stick around for 22 years.
OK, that’s one major tooltip annoyance fixed. That was one that was very annoying for some usage patterns, but never really <i>debilitating</i>. But if we’re trying to fix ancient tooltip bugs, here’s one that <i>is</i> debilitating for some users:<p>Tooltips are positioned relative to cursor position, below and to the right, but <i>don’t take cursor size into account</i>, and so if you have a comparatively large cursor, it occludes the tooltip.<p>This has been filed in a couple of guises a few times, starting twenty years ago: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=248718" rel="nofollow noreferrer">https://bugzilla.mozilla.org/show_bug.cgi?id=248718</a>, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=296191" rel="nofollow noreferrer">https://bugzilla.mozilla.org/show_bug.cgi?id=296191</a>, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=557754" rel="nofollow noreferrer">https://bugzilla.mozilla.org/show_bug.cgi?id=557754</a>, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1712669" rel="nofollow noreferrer">https://bugzilla.mozilla.org/show_bug.cgi?id=1712669</a>. (I don’t really get why bug 248718 and bug 557754 were closed as duplicates of bug 1712669; I tend to feel that the oldest one should be the canonical one almost as a matter of <i>principle</i>, especially when it’s <i>so</i> much older.)<p>This will affect many more users now than twenty years ago, because some time during Windows 10 they added a proper cursor size scale, so you can easily get a huge cursor (which I strongly suggest people try; I was amazed at how much it improved things, except for this class of bug). The old “extra large” cursor was equivalent to what’s now size 3 and the scale now goes up to <i>15</i>, if I remember from a few years ago accurately. Size 4 is already enough to lose a couple of characters from the start of tooltips.<p>(This is all about <i>native</i> tooltips, but naturally this is also a problem with DOM-based fake tooltips in web pages: they have no access to cursor dimension information, so no way to be certain of dodging the cursor. I recommend placing such tooltips above the cursor position, as that’s the <i>most likely</i> to be clear. Bug 1712669 comments 5 and 6 observe how this is a problem on Bugzilla itself—they put a DOM fake tooltip below on dates.)
Here is another good one: <i>too easy to hit CTRL+Q instead of CTRL+W</i> <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=52821" rel="nofollow noreferrer">https://bugzilla.mozilla.org/show_bug.cgi?id=52821</a><p>Only 20-and-a-half years to fix that one! In this case it wasn't because nobody got around to it, but because people could not agree on the fix, even though more or less everyone agreed that the old behavior was bad.
So you're telling me there's still some hope for my favorite JIRA tickets[1]!<p>1. <a href="https://jira.atlassian.com/issues/?jql=statusCategory%20%3D%22To%20Do%22%20and%20project%3D%22Jira%20Cloud%22%20%20order%20by%20votes%20desc" rel="nofollow noreferrer">https://jira.atlassian.com/issues/?jql=statusCategory%20%3D%...</a>
Funny some guy on HN was just arguing with me the other day that the oldest Firefox bug was 11 years old and that they fixed over 1,000 bugs in their last release. I tried to search their bug tracker to see if this was true but the web server doing the searches was unresponsive.
Ah, something extremely similar affects SyncTrayzor on Windows too! <a href="https://github.com/canton7/SyncTrayzor/issues/760">https://github.com/canton7/SyncTrayzor/issues/760</a>
I love Mozilla and I too have experienced this bug. I'm glad this has been fixed even it didn't annoy me that much. But it solidifies my choice in browser.<p>Brb while I test Sonoma to see if I can create two separate egg timers with Siri...
I'd always thought this was just from my Win 10 install being "crufty" (a few years old, with some hardware swapped along the way).<p>Never ran into it on my Linux box so I thought it was just Windows weirdness.
Lots of software have problems with persisting tooltips. I regularly have tooltips from VS Code getting "stuck" and can't be removed until I close the application.
I actually saw this happen even more in the Linux MS Teams client (which uses Electron or similar I think?), but I've encountered it with Firefox as well.
this problem <i>plagues</i> me, I even saw it today, and I'm up-to-date on the latest Firefox for Fedora, I wonder if it's rolled out yet? Here's the thing, though, they probably didn't fix it for me: I use focus-follows-mouse, so probably in my case Firefox will think it has the focus (because it does briefly), but it's just a little scrap peaking out from under a stack of other windows.
It would be good if Mozilla were to now fix other well-known bugs that have been in Firefox for decades.<p>First, copying/pasting highlighted webpage text with Ctrl-C/V is unreliable (no text in paste) and copying via the context menu must be used if one wants it to work every time.<p>Second, selecting text with mouse is awkward and irregular in many webpages. Moreover, whether one selects text from the right or the left makes a difference (it's often much harder to select one way than the other).<p>Third, it is impossible to select only part of a URL in a webpage and only the full address is selected (and even then just selecting the address from other text is often difficult). One has to paste the full address into a text editor and select the wanted section of the URL from there. Why would one want to do this? Well, the URL may be a long address to a specific page on a website and before or after one visits that page one may want to visit its homepage so copying only the homepage section of the address makes sense.<p>Mozilla, your text selection capability in Firefox is essentially not fit for purpose.<p>Forth, entering dialogue into a box like I'm doing here on HN to post this text is always fraut with the risk of losing it before the text is posted. Accidentally refreshing the page often happens before posting and thus the text is lost irretrievably which is damn annoying if one has written a lot of text. Simply, there is no progressive save or UNDO in this situation. Why on earth not? Wordprocessors have had undo for decades so why not Firefox? (If I know the text is more than a sentence or two I edit with an external editor. Mozilla, this is unacceptable and you ought to be ashamed of the fact.)<p>The fact that Firefox does not have undo or that text selection is broken amounts to primitive and unfinished engineering (especially so after decades of Firefox development), thus one has to speculate what other important code is also so rough and ready and unfinished that we cannot see!<p>Mozilla, if any of you ever bother to read this then you ought to know how annoying these bugs are. (One has to wonder if you ever bother to use your own product—or perhaps you've never investigated how your users use your product.)<p>One can understand bugs and limitations in a new product but they all ought to have been polished out after several decades of development. If you want to recapture browser market share then you could start by fixing these annoyances. Moreover, it would be a good PR exercise if you explained why these bugs have been ignored for so long. (Incidentally, there are other issues I've not mentioned here.)<p>BTW, many of us have complained about these problems for years and we've never received an explanation as to why you've never address them (it's little wonder your market share has dropped).
Software is gradually turning into a similar pattern of layering like sediment. With most modern "hardware level" applications, there are still layers of OS magic happening under the hood.<p>We're now into maybe decade 4-ish of software dependency.<p>There was a scene in one of Alastair Reynold's books where a character basically was a computational archaeologist. That resonates with me a lot.<p>In a couple centuries, it's not a terrible prediction of the future that software stacks will accumulate cruft over time and debugging certain issues will require immense financial effort to both dig through the layers of software commits and historical proposed merge commits, plus adding extra tests on top of bedrock code and its fixes.<p>No idea what this will look like. I imagine easily executed functions will pop up in mixed pip's and npm's that are easily recreated functionality every decade, regardless of prior art. Every new programmer wants to make a stamp on the world.<p>There's some saying about history repeating itself, but I'm dumb and don't remember.