Firefox tooltip bug fixed after 22 years
bugzilla.mozilla.org
bugzilla.mozilla.org
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: https://youtube.com/@mikeconleytoronto
Later on I figured out how to build the apps, which was a bear, especially on Windows. Firefox, Thunderbird, and the whole Mozilla Suite which was still a thing back then, with integrated browser, mail, HTML editor etc. And finally contributed some bug fixes of my own. Nothing significant, we're talking like fixing typos and misaligned icons, but it still felt incredible to be shipping code that literal millions of people would use.
All of this was immediately useful in my first job out of school. I started out doing IT support and QA at a startup but quickly found they had no build and deploy automation. Someone would push to SVN and you might not find out for days that it broke the build. I got them set up with a build server using what I had learned from Mozilla (Buildbot? Cruisecontrol? Hudson? Been too long) that would do a build on push and email the team if it couldn't compile or failed tests. Was pretty fun having a bunch of seasoned developers ask me "how the hell does our IT guy know about all this shit?" I was able to carve out a DevOps role for myself before that term existed, thanks to everything I learned playing with Mozilla in my free time.
This is a roundabout way of saying I totally agree, hacking on Mozilla projects is a great way to get real world experience :)
I had forgotten about CruiseControl. Long ago, I had a gig for an avionics developer in a team whose technical lead had gotten deep into agile and had mostly sane practices (sources control, build scripts and automated tests were not a given back them).
Still, we had a colleague that was often a bit to quick to commit broken builds or failed tests to the trunk. One day, I stumbled upon this program - CruiseControl - designed to automate build and test tasks. I had no notion that continuous integration was a thing.
As a practical joke, I setup a VM, installed Cruise Control, gave access to our subversion server and created some jobs using existing Ant tasks, just to email blast the team when a broken build was committed.
It got positive results way beyond the initial intent (mainly by eliminating "build worked on my machine"). Two years later, all SW projects of the company had been moved to Hudson.
I too got a big head start by volunteering for Mozilla.
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...
A videogame generally wants none of that: no windows controlled by the OS, no OS-provided cursor because it won't fit the game's visual theming (or makes no sense in that kind of game at all), other behaviors on the mouse, different keyboard behavior, and (if they could get away with it) no multitasking; you need all that CPU for game stuff. So shifting a desktop PC from "not playing a game" mode to "playing a game" mode is, historically, an extremely modal shift involving kicking most of the OS to the curb, rejecting its reality and replacing it with your own.
Modern OSes have better abstractions for this, and modern computers can actually tolerate running background tasks alongside high-performance games (we've crossed a threshold where most reasonably-optimized games can't find anything to do with all your CPU because the experience is still long-polled by human perception speed). But the fundamental design tension is forever there.
1. Make the UI around profiles better 2. When I click a link anywhere outside of the browser, open it in the last active window.
Number 2 is the most important honestly
Code powering Profiles is probably is much more convoluted than people have realized.
Addendum: The earliest reference I can find is around 2000 (https://math.vanderbilt.edu/schectex/wincd/tips_netscape.htm), which coincides with Netscape 3/4 era.
I think profiles are not supported as first class citizens, still.
Shall that be improved? Yes. Will that be easy? I don't think so.
UI is top of the proverbial iceberg. It's relatively easy to modify it.
I’m saying this as a lover of 90s dense interfaces, like Eclipse.
I, for one, would like the last active container to be used.
If I relied on "last active" I would frequently get things opening up in the wrong place just because say, last time I was in a browser I happened to be in a my personal profile, and 30 minutes later, I click a link in work Slack.
this may not be easy to fix.
the problem here is how the url opener selects the process.
at that point it can't even know which process has the last active window. it would have to connect to both processes and request that information instead of just sending the url to the most recent process in the list. and then each process would have to return when it was last active to be able to choose which one of these was active more recently. this may not be possible without some more elaborate book-keeping of timestamps when a window gets activated.
this increases the complexity of the url opening feature in a non-trivial way.
it may not even be desirable to handle this in firefox only.
what if you run chromium and firefox? now you want a generic url opener that sends the url to the last active browser.
what we really want here is to have a generic way to send an url to an open window.
Forgive me as I'm not a "real" desktop programmer, only web technologies really, but...
Is there not some master process that knows the basic details about its various separate processes? I mean, the main process has to be able to tell the others to quit, right? I would have thought it could keep track of the metadata of each for coordination purposes, like, as a process's window becomes Front it could check in and say 'yo this is process 12345, I'm profile X and I'm becoming Active.'
kill in X11 is done by sending a message to the window to go away. in the normal case this triggers an exit in the process, but it is possible for the process to keep running or even open a new window. X11 can not force a program to really terminate because again the process could be from a different machine or a different user.
there are two ways to talk to a process: one is to find the X11 window and send messages to it through the X11 protocol. this is done for example to share clipboard contents. it would be possible to send urls that way too.
the other is to find the unix process, and use some rpc mechanism to talk to it that way.
as far as i can tell, firefox is using the unix process. this may be because of the cross platform nature of firefox. process RPC is easier to do in a cross platform way. the X11 method does not work on windows or MacOS, so that would mean that each system needs custom code to handle this.
The ux is currently horrible because you have to run multiple copies of the browser
What I want to do is sandbox my accounts, specifically my work account. Here's a sceneario
I click a link in slack, I want the link to open in the work container.
How do I do this?
Because using containers, It will default open in the default container, i then have to right click the tab, and say "open in work container" .. which then opens that tab again, in the Work Container.
What I want is to not have to do that extra work. Click link -> Work Container.
You can't, at least, not default... you need to add extra plugins, like Multi-Account containers or whatever the plugin is called. That's a LOT of work for the average user. Compared to profiles where when you click the link, it opens in the last active window, which remembering windows are profiles, will be most likely the right profile. So if im working constantly on my work profile window, i click slack, and then click a link, its right back where i want.
The problem with container tabs, is that its tabs, not windows. So is there any way i can say to firefox "this new window is WORK Containers please"
It's available at https://github.com/honsiorovskyi/open-url-in-container and Mozilla Extension store, so you can directly install it.
I think you can register a new "application" to open links, not set at default, and use Right Click -> Open With -> Firefox (WORK CONTAINER).
Will that work?
To me containers still don't replace profiles.
These people wired tons of plugins on their browsers, VSCode and Obsidian installations, created web sites and tools which broke new ground and their tools were running on distributed systems at very good speeds. Some of these tools requires human years to develop even by “computer people”, yet these people sat with their partners during the pandemic and developed these amazing things while wearing trainers and drinking coffee casually.
These people would make this plugin draw circles up in the air while most of us “not average users” are reading the docs.
So, what is an average user? By your definition I’m an average user, because I use containers, but I didn’t use this extension, but found it in five minutes, because you wanted a solution.
Now I’ll install and use it fully tomorrow morning, before my coffee gets warm. Because it’s worth it.
It was always such a pain having to re-focus almost every firefox window until it disappeared to figure out where it'd come from because it'd often be something fairly generic like "Previous" that it'd choose to tooltip and push in front of absolutely everything else.
On occasion (a smaller screen) it could be quite annoying as it might interfere with the display of a form or other critical element.
Looking forward to the update and the next 22 years of firefox not just being bugfree but being the impactful application it once was.
Apparently it can be fixed by the application
If you see the five line fix for the bug and think "I could have done this!" You could!
The actual answer is "why didn't't I?"
So to answer that question for myself : How easy is it to compile Firefox and run the test suite?
The long bug hunting bit after that is the fun part.
If Firefox was on GitHub (or even a self-hosted GitLab) where I can just fork it, play around and have the exact same CI, that would be an entire different story. I whish it was as easy as that.
The repo is also mirrored on GitHub for convenience, though PRs are not accepted through GitHub: https://github.com/mozilla/gecko-dev
The build instructions start with a script (“mach bootstrap”) that will download and install all the blessed tools and SDKs needed to build: https://firefox-source-docs.mozilla.org/setup/index.html
Depending on your network and computer, it can be possible to download the source and compile and run your own Firefox build in less than 20 minutes.
Then one line to install the command line tooling to submit patches and another line to submit a patch (or a patch series).
All the docs are there for all major platforms, aimed at first timer in our code base: https://firefox-source-docs.mozilla.org/contributing/contrib...
It used to be much more complex than that but this isn't the case anymore. Using GitHub (that we need to use anyways because lots of projects and lots of web standards use it) feels like banging two rocks together compared to what our tooling can do, especially at that scale.
Source: I work at Mozilla and frequently onboard contributors of all backgrounds and levels.
- git is not as modern as mercurial (no absorb, no evolve, no nice ncurse gui, weird explicit branching model). I've been using both daily for more than ten years, but mercurial is largely superior in every respect
- no way to properly do patch stacks and proper reviews, with static analysis and linting integrated into the review tool, no way to lose comments by force push or that kind of thing (phabricator is amazing)
- no way to properly do private issues for security bugs or touchy audits that could reveal large problems
- no hierarchical categories for issues, no severity, priority, little provision for advanced filtering for a project our size. Bugzilla is very nice and much better than anything else I've tried. You can use tags for a lot of that on gh but it's messy - code browsing is primitive compared to https://searchfox.org/ (but most code browsing tool are, in comparison)
- my notifications are completely flooded by lots of useless information on GitHub, but that might be fixable
- our CI system (treeherder/taskcluster) scales, works on Linux/Mac/windows/Android and a bunch of version and arch, integrated with all of the other tools mentioned. Things such as auto-running tests based on the content of the patch, automatic categorization and prioritization of intermittent test failures, or auto-recording test failures and offering a pernosco recording showing the issue are just some of the features that we use daily without even thinking
There's probably a lot of other stuff that is better, but that's a nice start. If GitHub had a real patch stack management story, a real issue tracker and a real review tool it would go a long way, but that's not the case.
I had some coworkers who preferred Mercurial, the argument tends to be that it has a better user interface (not hard to beat Git on that one...), but also because of its immutability. Core Mercurial makes it really hard to change history, and branches are strongly tied to commits instead of being moving bookmarks (I know that Mercurial has bookmarks, but we used branches). Simple and stable.
Now the arguments you give for Mercurial are absorb and evolve, commands designed for rewriting history, something that we felt Mercurial tried so hard to make difficult (for example by hiding them behind extensions). Something I find quite interesting, has Mercurial changed so much during last years? Maybe that's what you mean by "modern" even though they came out at almost the same time.
About GitHub. The simplicity of its bug tracker is supposed to be a feature. Too often, we find ourselves with all sorts of fields that ultimately doesn't serve much purpose. For example, what about priority and severity? I understand priority: sort by priority to pick the ones you should work on, but then, what's the point of severity? If both are correlated, one of them is redundant, if they are not, which one should I pay attention to? And what's the severity of a feature request? And am I allowed to make the cosmetic feature I really want a critical priority?
GitHub has tags and a description, this can already do a lot. It is messy, but real life is messy, and often, in bug trackers with lots of fields and categories, I don't know what to put in there because it doesn't really apply, but I still put something because I have to, contributing to noise, which is also messiness but shifted elsewhere.
This is not a criticism of the Mozilla way, just that there is more than one way of doing things.
GH issues as a bug tracker feels really too simplistic compared to proper bug trackers. You can work around the deficiencies with labels and github actions to some extent, but it always feels like a hack. Why invent some ad-hoc labels with unclear meaning if you can use a superior bug trackers where you have fields as a first class citizen?
Although with GH, when you use all of those, the issue list still looks visually nice. Compared to GitLab, where if you go to GL tracker on GL project, you see issue list with 100 labels on each items, of different colors, the UI of the issue list is a madness.
(Been using GH on a daily basis at bigcorp for years for code tracking, but tickets are usually tracked in a behemoth like jira. I opened a few bugs in bugzilla over the years.)
Having dynamic types and freeform JSON sounds nice when doing toy things, but at some point you're like "hmm I want to find all bugs which affected Component X and have been fixed between version 83 and 90" and then some structure is good. (Arguably, GH issues labels could be used for this though.)
Here's a cool class diagram with emojis: https://asuth.searchfox.org/mozilla-central/query/default?q=...
Personally I think I got used to Git since it's 99.99% of what I use today. There are definitely pain points to it, but just like most people it's kind of become "the way it is", which I don't think is healthy. While Git has helped revolutionized the way SCM works, it's far from perfect (and it still does certain things worse than a traditional centralized SCM like binary file management and renaming files), and I think its prevalence sometimes puts people in a collective blindspot/groupthink. Imagine if you are in your 20's and Git is the only SCM you have used, everything other than Git would either be old-school or weird.
I definitely agree on GitHub though. I think it's quite nice for small projects (I manage one myself) but I don't see how it's usable for a serious large software project for reasons you mentioned. Even simple things like correctly linking issues together, or code review tools just seem severely lacking to me.
Then you merge ("land") the patch stack in one unit, and it's tested in one unit, and bisection tooling knows that it is the case and it's nice.
https://web.archive.org/web/20160309055829/http://www.bash.o...
Code search is here: https://searchfox.org/mozilla-central/ I’ve never seen a better search tool.
It’s become pretty straightforward to build in the past few years. You pretty much just need your system SDKs (which are listed), python, and git or hg (which is Python anyway!).
I promise you that you don’t need CI until you have a patch that works locally.
It might just be me but gnome and it's associated apps seem to have come a long way recently, and I can't help but think it's because they moved to an opinionated but modern build system (meson) and all the repos are easy to access / contribute to on their gitlab instance.
(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.)
I just did some testing and getting it to happen is as simple as hovering over it, And swapping to another virtual desktop before the popup shows up with firefox not being the new active application.
The main culprit seems to be a desynchronized event delivery, where you are expected to receive an event when the cursor exits but somehow weren't, for example because the window focus was lost so no further mouse events couldn't be delivered (depending on OS and preferences). Unless there is a dedicated way to reliably detect such cases (e.g. DOM `onmouseleave` or `onmouseout`), workaround and hacks would be needed---for example when the window focus was lost it can generate synthetic events.
https://tronche.com/gui/x/xlib/events/window-entry-exit/
typedef struct {
int type; /* EnterNotify or LeaveNotify */
unsigned long serial; /* # of last request processed by server */
Bool send_event; /* true if this came from a SendEvent request */
Display *display; /* Display the event was read from */
Window window; /* ``event'' window reported relative to */
Window root; /* root window that the event occurred on */
Window subwindow; /* child window */
Time time; /* milliseconds */
int x, y; /* pointer x, y coordinates in event window */
int x_root, y_root; /* coordinates relative to root */
int mode; /* NotifyNormal, NotifyGrab, NotifyUngrab */
int detail;
/*
* NotifyAncestor, NotifyVirtual, NotifyInferior,
* NotifyNonlinear,NotifyNonlinearVirtual
*/
Bool same_screen; /* same screen flag */
Bool focus; /* boolean focus */
unsigned int state; /* key or button mask */
} XCrossingEvent;
typedef XCrossingEvent XEnterWindowEvent;
typedef XCrossingEvent XLeaveWindowEvent;
https://tronche.com/gui/x/xlib/events/window-entry-exit/norm...
https://tronche.com/gui/x/xlib/events/window-entry-exit/grab...
https://tronche.com/gui/x/xlib/events/input-focus/
https://tronche.com/gui/x/xlib/events/input-focus/normal-and...
https://tronche.com/gui/x/xlib/events/input-focus/grab.html
https://tronche.com/gui/x/xlib/events/key-map.html
And then you have colormaps and visuals:
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
>The color situation is a total flying circus. The X approach to device independence is to treat everything like a MicroVAX framebuffer on acid. A truly portable X application is required to act like the persistent customer in Monty Python’s “Cheese Shop” sketch, or a grail seeker in “Monty Python and the Holy Grail.” Even the simplest applications must answer many difficult questions:
WHAT IS YOUR DISPLAY?
display = XOpenDisplay("unix:0");
WHAT IS YOUR ROOT?
root = RootWindow(display, DefaultScreen(display));
AND WHAT IS YOUR WINDOW?
win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1,
BlackPixel(
display,
DefaultScreen(display)),
WhitePixel(
display,
DefaultScreen(display)));
OH ALL RIGHT, YOU CAN GO ON.
(the next client tries to connect to the server)
WHAT IS YOUR DISPLAY?
display = XOpenDisplay("unix:0");
WHAT IS YOUR COLORMAP?
cmap = DefaultColormap(display, DefaultScreen(display));
AND WHAT IS YOUR FAVORITE COLOR?
favorite_color = 0; /* Black. */
/* Whoops! No, I mean: */
favorite_color = BlackPixel(display, DefaultScreen(display));
/* AAAYYYYEEEEE!! */
(client dumps core & falls into the chasm)
WHAT IS YOUR DISPLAY?
display = XOpenDisplay("unix:0");
WHAT IS YOUR VISUAL?
struct XVisualInfo vinfo;
if (XMatchVisualInfo(display, DefaultScreen(display),
8, PseudoColor, &vinfo) != 0)
visual = vinfo.visual;
AND WHAT IS THE NET SPEED VELOCITY OF AN XConfigureWindow REQUEST?
/* Is that a SubstructureRedirectMask or a ResizeRedirectMask? */
WHAT??! HOW AM I SUPPOSED TO KNOW THAT? AAAAUUUGGGHHH!!!!
(server dumps core & falls into the chasm)But ever since then, no other window system really gave a flying fuck about that, and just blithely drops events on the floor or delivers them to the wrong place, gaslighting and training the users to make up for it by clicking slowly and watching the screen carefully and waiting patiently until it's safe to click or type again, before proceeding.
This kind of loosey-goosey race condition input handling problem that's intrinsic to every "modern" window system and web browser and UI toolkit is exactly why bugs like this tooltip bug appear across all platforms, and go unfixed for 22 years, because everybody is gaslighted into thinking that's just the way it has to be, and they're the only one with the problem, and it's unfixable anyway, and even if it were fixable, they deserve it, etc...
What's could ever go wrong with the occasional indestructible floating randomly worded tooltip blocking your desktop or video player or game? It's "Tooltip Roulette"! Just hope you don't accidentally screen share a naughty tooltip with your mom during a zoom meeting.
(Not that NeWS was without its own embarrassingly stuck popup windows, but NeWS had an essential utility for removing embarrassing windows called "pam", named after the sound you made when you used it, or maybe the original easy cleanup canola oil spray ideal for use in cooking and baking.)
Failing to properly support synchronous event distribution makes it impossible for window managers (ESPECIALLY asynchronous outboard X11 window managers running in a different process than the window system) to properly and reliably support "type ahead" and "mouse ahead".
For example, when a mouse click on a window or function key press changes the input focus, or switches applications, or moves a different window to the top, or pops up a dialog, or opens a new window, the subsequent keyboard and mouse events might not be delivered to the right window, because they are not synchronously blocked until the results of the first input event are handled (changing where the next keyboard or mouse events should be delivered to), so clicking and typing quickly delivers the keystrokes to the wrong window.
I find it extremely annoying to still be forced to use flakey leaky "modern" window systems for 37 years after getting used to NeWS's perfect event distribution model, which is especially important on slow computers or networks (i.e. dial-up modems), or due to paging or thrashing because of low memory (NeWS competing with Emacs), or any other system activity, and especially for games and complex real time applications.
There are still to this day many AAA games that force you to hold a key down for at least one screen update, because they're only lazily checking for key state changes on each draw or simulation tick, instead of actually tracking input events, otherwise they don't register sometimes if you just tap the key, and you have to slowly mash and wait, especially when the game gets slow because there's a lot of stuff on the screen, or has a hiccough because of garbage collection or autosave or networking or disk io or...
James Gosling first wrote the importance of safe synchronous event distribution in 1985 in "SunDew - A Distributed and Extensible Window System":
http://www.chilton-computing.org.uk/inf/literature/books/wm/...
>5.3.3 User Interaction - Input
>The key word in the design of the user interaction facilities is flexibility. Almost anything done by the window system preempts a decision about user interaction that a client might want to decide differently. The window system therefore defines almost nothing concrete. It is just a loose collection of facilities bound together by the extension mechanism.
>Each possible input action is an event. Events are a general notion that includes buttons going up and down (where buttons can be on keyboards, mice, tablets, or whatever else) and locator motion.
>Events are distinguished by where they occur, what happened, and to what. The objects spoken about here are physical, they are the things that a person can manipulate. An example of an event is the E key going down while window 3 is current. This might trigger the transmission of the ASCII code for E to the process that created the window. These bindings between events and actions are very loose, they are easy to change.
>The actions to be executed when an event occurs can be specified in a general way, via PostScript. The triggering of an action by the striking of the E key in the previous example invokes a PostScript routine which is responsible for deciding what to do with it. It can do something as simple as sending it in a message to a Unix process, or as complicated as inserting it into a locally maintained document. PostScript procedures control much more than just the interpretation of keystrokes: they can be involved in cursor tracking, constructing the borders around windows, doing window layout, and implementing menus.
>Synchronization of input events: we believe that it is necessary to synchronize input events within a user process, and to a certain extent across user processes. For example, the user ought to be able to invoke an operation that causes a window on top to disappear, then begin typing, and be confident about the identity of the recipient of the keystrokes. By having a centralized arbitration point, many of these problems disappear.
[...]
>Hopgood:
>How do you handle input?
>Gosling:
>Input is also handled completely within PostScript. There are data objects which can provide you with connections to the input devices and what comes along are streams of events and these events can be sent to PostScript processes. A PostScript process can register its interest in an event and specify which canvas (a data object on which a client can draw) and what the region within the canvas is (and that region is specified by a path which is one of these arbitrarily curve-bounded regions) so you can grab events that just cover one circle, for example. In the registration of interest is the event that you are interested in and also a magic tag which is passed in and not interpreted by PostScript, but can be used by the application that handles the event. So you can have processes all over the place handling input events for different windows. There are strong synchronization guarantees for the delivery of events even among multiple processes. There is nothing at all specified about what the protocol is that the client program sees. The idea being that these PostScript processes are responsible for providing whatever the application wants to see. So one set of protocol conversion procedures that you can provide are ones that simply emulate the keyboard and all you will ever get is keyboard events and you will never see the mouse. Quite often mouse events can be handled within PostScript processes for things like moving a window.
NeWS Window System:
https://en.wikipedia.org/wiki/NeWS
>Design [...]
>Like the view system in most GUIs, NeWS included the concept of a tree of embedded views along which events were passed. For instance, a mouse click would generate an event that would be passed to the object directly under the mouse pointer, say a button. If this object did not respond to the event, the object "under" the button would then receive the message, and so on. NeWS included a complete model for these events, including timers and other automatic events, input queues for devices such as mice and keyboards, and other functionality required for full interaction. The input handling system was designed to provide strong event synchronization guarantees that were not possible with asynchronous protocols like X.
NeWS 1.1 Manual, section 3.6, p. 25:
http://www.bitsavers.org/pdf/sun/NeWS/NeWS_1.1_Manual_198801...
>Processing of input events is synchronized at the NeWS process level inside the NeWS server. This means that all events are distributed from a single queue, ordered by the time of occurrence of the event, and that when an event is taken from the head of the queue, all processes to which it is delivered are given a chance to run before the next event is taken from the queue. When an event is passed to redistributeevent, the event at the head of the event queue is not distributed until processes that receive the event in its redistribution have had a chance to process it. No event will be distributed before the time indicated in its TimeStamp.
>In some cases, a stricter guarantee of synchronization than this is required. For instance, suppose one process sees a mouse button go down and forks a new process to display and handle the menu until the corresponding button-up. The new process must be given a chance to express its interest before the button-up is distributed, even if the user releases the button immediately. In general, event processing of one event may affect the distribution policy, distribution of the next event must be delayed until the policy change has been completed. This is done with the blockinputqueue primitive.
>Execution of blockinputqueue prevents processing of any further events from the event queue until a corresponding unblockinputqueue is executed, or a timeout has expired. The blockinputqueue primitive takes a numeric argument for the timeout; this is the fraction of a minute to wait before breaking the lock. This argument may also be null, in which case the default value is used (currently 0.0083333 == .5 second). Block/unblock pairs may nest; the queue is not released until the outermost unblock. When nested invocations of blockinputqueue are in effect, there is one timeout (the latest of the set associated with current blocks).
>Distribution of events returned to the system via redistributeevent is not affected by blockinputqueue, since those events are never returned to the event queue.
The X-Windows Disaster:
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
>Ice Cube: The Lethal Weapon [...]
>The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn’t work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It’s so difficult, that many of the benefits just aren’t worth the hassle of compliance. And when one program doesn’t comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.
Window Manager Flames:
http://www.art.net/~hopkins/Don/unix-haters/x-windows/i39l.h...
>Why wrap X windows in NeWS frames? Because NeWS is much better at window management than X. On the surface, it was easy to implement lots of cool features. But deeper, NeWS is capable of synchronizing input events much more reliably than X11, so it can manage the input focus perfectly, where asynchronous X11 window managers fall flat on their face by definition. [...]
>If NeWS alone manages the input focus, it can manage it perfectly. An X window manager alone cannot, because it runs in a foreign address space, and is not in a position to synchronously block the input queue and directly effect the distribution of events the way NeWS is. But even worse is when an X window manager and NeWS both try to manage the input focus at once, which is the situation we are in today. The input focus problem could be solved in several ways: OWM solves the problem elegantly, as PSWM did in the past; OLWM could be made NeWS aware, so that when our own customers run our own external X window manager on our own server that we ship preinstalled on the disks of our own computers, OLWM could download some PostScript and let NeWS handle the focus management the way it was designed.
>It's criminally negligent to ship a product that is incapable of keeping the input focus up to date with the cursor position, when you have the technology to do so. Your xtrek has paged the window manager out of core, and the console beeps and you suddenly need to move the cursor into the terminal emulator and type the command to keep the reactor from melting down, but the input focus stays in the xtrek for three seconds while the window manager pages in, but you keep on typing, and the keys slip right through to xtrek, and you accidentally fire off your last photon torpedo and beam twelve red shirt engineers into deep space!
This happens several times a day.
(Lunix X11 with MATE's Marco wm)
Turns out that while gaming I often have a Youtube video playing in one browser tab, and use another browser tab to look up game-related information. So it is really common for me to interact with the tab bar (which triggers the tooltip) right before alt-tabbing into my game.
During day-to-day browser use my cursor is almost always located somewhere over the website content - which rarely triggers a tooltip.
However, I do frequently get an innocent bug, where opening my bookmark toolbar's extension (the >> icon in the top right) results in it displaying all the bookmarks in a drop-down list, instead of the ones not appearing on the toolbar.
On the downside, this is sorta a "wrong" fix. Tooltips should 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.
Especially true if breakpoints don't work :)
- if (tooltipNode->GetComposedDoc() &&
- nsContentUtils::IsChromeDoc(tooltipNode->GetComposedDoc())) {
+ // Make sure the document still has focus.
+ auto* doc = tooltipNode->GetComposedDoc();
+ if (!doc || !nsContentUtils::IsChromeDoc(doc) ||
+ !doc->HasFocus(IgnoreErrors())) {
+ return NS_OK;
+ }
...
- }
}
return NS_OK;
1) remembering result of tooltipNode->GetComposedDoc() and adding the test of doc->HasFocus(IgnoreErrors()). Note that writing this one now is maybe easier than it was at the time the initial code was written, it could be the "auto" in this current semantic didn't exist in C++ (or the used compilers/platforms) at that time.
2) Explicit return. Instead of:
if (b)
X;
return OK;
if (!b)
return OK;
X;
return OK;
I recall reading some time ago that the work on XULRunner essentially came to a halt, and that components in Firefox/Mozilla that depend on XUL would slowly be phased out.
But does that mean that work on the XUL runtime and components in Firefox also effectively came to a halt? I figured that most of these really old XUL bugs in Firefox were never going to be fixed, instead replacing a whole layer/component dependent on XUL was seen as a better use of time and resources.
Edit: anyone have a good diagram of the layers/components in Firefox. Something that can illustrate where Quantum, Gecko, XUL, etc all live in Firefox. It would be really cool (doubt it exists) if there was an animated diagram that would show the changes of this stack overtime.
If so - is it normal to do indention changes and actual code changes in the same commit?
Personally, I would first have committed the indention changes and then did a second commit with the coded changes.
Basically it just adds a one line check near the top of a ShowTooltip() function for whether "doc->HasFocus(IgnoreErrors())", and, if not, returns early.
and every time i think about the problem i stumble over python where the two can't be separated.
i believe in the end a better solution would be to mark whitespace changes in a different color. or even better mark each character that changed, not just the line.
in other words: we want better diff tools
Bug is fixed, please retest :)
- show the tooltip - rely on move events on the main window to hide it
the move events are usually received only when the window is visible (and focused depending on the os), unless you take extra measures to grab the pointer and/or listen on global events, which involves more trickery to work right.
It's the classic scenario where a decent system toolkit has this figured out and solved for you, while doing the same by hand looks somewhat easy and normally works 95% of the time, but fails in odd ways and drives your power users crazy.
Driving UIs heavily by keyboard and shortcut is the sure-way to hit that remaining 5% all the damn time nowdays...
Here's the story of a 33 year old bug in yacc that was fixed in 2008: https://undeadly.org/cgi?action=article&sid=20080708155228
By placing large allocations (those larger than half the page size) at the end of a page, I would think it also allows them to be resized in more cases. Smaller allocations can be then made in the gap, until it's filled. Then, if realloc is called on the large allocation and enough space remains for the difference, it can be shifted backward with memmove. Whereas, the large allocation is placed at the first available position and further allocations are made after it, it has no space to resize.
Disclaimer: I haven't implemented a memory allocator, so my understanding may be off.
What beautiful news if this indicates that some other old bugs will eventually be fixed as well!
if you want to play the long game you may also predict if younger bugs get fixed more than 20 years after reporting. (if the bug gets fixed earlier than 20 years then the prediction becomes void)
place your bets!
*terms and conditions apply. firefox developers are not eligible.
It also affects Thunderbird.
I had no idea it was a well known, 22 year old bug.
You'll collect low effort comments, but at least it avoids duplicates and the discussion is preserved in-thread.
That impression lead me to meaningfully contribute in the bugtracker.
[Edit] OIC, it's a heisenbug. Funny though; I'm a longtime FF user, and I don't recall witnessing it.
Tooltips should be removed entirely instead of fixing 22 year old bugs.
Wild.
My solution was to activate/trigger another tooltip, that would make the frozen one disappear, and hope the new one would behave normally.
Wasn't ready to give up Firefox, but can't say that the thought didn't cross my mind.
Now that I think about it, still to this day I see similar issues in other apps where some kind of popup/overlay/tooltip persists across tabs/windows/applications.
Still, I trust Mozilla more than some random xyzPass.
> 148624 - (tooltip-ghost) Tooltips persist in foreground when Firefox is in background
My point here is a meta point: it’s great that we can change the titles to something more descriptive.
Edit: nvm, I found the link in the linked page: https://hg.mozilla.org/mozilla-central/rev/8ae372dc88d1
Bug squashed!
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
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?
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..
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.
Tooltips are positioned relative to cursor position, below and to the right, but don’t take cursor size into account, and so if you have a comparatively large cursor, it occludes the tooltip.
This has been filed in a couple of guises a few times, starting twenty years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=248718, https://bugzilla.mozilla.org/show_bug.cgi?id=296191, https://bugzilla.mozilla.org/show_bug.cgi?id=557754, https://bugzilla.mozilla.org/show_bug.cgi?id=1712669. (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 principle, especially when it’s so much older.)
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 15, 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.
(This is all about native 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 most likely 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.)
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.
1. https://jira.atlassian.com/issues/?jql=statusCategory%20%3D%...
Brb while I test Sonoma to see if I can create two separate egg timers with Siri...
Never ran into it on my Linux box so I thought it was just Windows weirdness.
That comment aged so well.
(Also, your username triggers me in a wildcard sort of way.)
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.
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).
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.
Mozilla, your text selection capability in Firefox is essentially not fit for purpose.
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.)
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!
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.)
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.)
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).
We're now into maybe decade 4-ish of software dependency.
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.
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.
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.
There's some saying about history repeating itself, but I'm dumb and don't remember.
Or at least it could do so, but may choose to force humans to fix those errors instead as payback for copilot.
Well more than 10 years ago we thought that we would have autonomous cars in 5 years.
Nothing says that AI can ever do more than generating convincing and eloquent bullshit (which is not always wrong in a quite impressive manner, I agree).
One is an idea for which there is no ground to base it on, the other is an existing thing which can be recreated. Quite the difference.
Really? For all we know, maybe next year someone discovers fundamentally new laws of physics that enable cold fusion, and we will never have autonomous vehicles.
You can say that you like the other guess better than mine, but you should still realize that it is just that: a guess. Wanna see guesses that turned out to be completely wrong? Just check what companies like McKinsey predicted 10 years ago. They just have no clue, but somehow made a business out of it.
And when they happen we exchange some old bugs for new ones.
There are onions[0] but IME people's natural instinct is to think they can just rebuild something rather than think they haven't considered all edge cases.
Small projects can be re-written; big projects like browsers, compilers, OSs require too much investment.
Or e.g. microsoft replaced WSL1 with a completely different approach in WSL2.
Sure it's still Windows but I would be surprised if most of today's code is the same it was in the year 2000.
Firefox kept some Netscape code for sure, but replaced its CSS engine, its JS engine, its XUL-based UI.
Not sure about Alastair Reynold but there’s Pham Nuwen in Vernor Vinge’s A Deepness in the Sky who is indeed that: a programmer archaeologist (and programmer-at-arms to exploit the weaknesses in the other party’s software midden).
I liked that Pham founds the Qeng Ho specifically so that he could be the one commissioning new software for the ships. He wanted to be the one putting hidden backdoors, secret passwords, and booby–traps into it. Of course it’s built on Unix, but if you’re paying attention you’ll notice that when someone enters a command they type “a column of text”.
He also built interstellar communication networks specifically so that civilizations that fell could rebuild more quickly (at least once they reinvented radio) and could learn the Qeng Ho language and systems in the process. But he also put in encrypted channels so that Qeng Ho traders would have inside information and therefore an edge against outside traders.
And then Nau gets his hands on it all, with his crew of Focused to examine every line of source code…
"History repeats itself, first as tragedy, second as farce."
Karl Marx
(And reducing accretion by having metalevel encoding of concepts)
In my experience corporate would rather have programmers accommodate the bug, or simply build around it, rather than pay for the dev and QA time required to produce and validate a fix for it.
This gets gnarly because you end up with sections of the codebase that are designed around the bug happening. A while back I volunteered to fix a particularly egregious bug, but my pull request was denied because people were worried that fixing it would open up a can of worms. Leadership said that it would be too much of a burden for QA to regression test and we couldn’t be sure it wouldn’t break other things. I settled for leaving a detailed comment explaining the bug and moved on.
so that you can build on proven (e.g. theorem solver / hardened / guarenteed) protocols and automatically make whatever version of a "website" the 2030's has... but without RCEs.
Don't make me link Joel Spolsky's never do a rewrite.
In 200 years it'll just be AIs, who will create custom AIs to accomplish a task, who will create legions of other AIs to carry out tasks. It'll be code writing code writing code that's completely beyond human comprehension.
Who knows if humans will take part at all (or even be around).
See 3D printing, few years ago everyone was into "0-mile" manufacturing and how it will solve the housing crisis, because we are just going to print houses.
- Point out that most 3D printing is plastic? Recieve a derisive link to a journal article where some beleagured postdoc managed to push some protein paste through the extruder
- Point out that the 3D printer is orders of magnitude slower than the most geriatric fry cook? Get a five paragraph history of Moore's law. The fact that it no longer really applies to semicoductors doesn't matter, since we're making burritos!
- Point out that grinding an apple into paste and painstakingly reprinting it in an apple shape will always be more expensive than simply eating the apple? Hear a grand tale on the company becoming the sole global food preparation firm and thus having a monosopy on all farming products, enabling them to set their own price on their supplies.
I also will always hold a soft spot for the group promising a 3D printed dating site, but I'm pretty sure that one was a satire. Fill out a questionaire and get a perfect printed partner. Pages of blog posts describing their web stack (Rails and Mongo) in great detail, proving that they could scale to the billions of people who would be visitng their site. The actual technology that created custom sentient life was just "3D printing"
Uh... I... asking for a friend, do you recall the name? Google isn't helping. Them, I mean, it's not helping them.
Or those artificial food pills from more dystopic scifi.
200 years is a huge amount of time. The whole industrial revolution started around 200 years ago. 3d printing is still new by this standard. People overestimate impact of some technology in very short term and underestimate in medium or long term
Indeed, but this is somewhat the point? E.g. China was an empire (before it was a multiparty republic, before it was a Communist republic, before its government became whatever you want to call it today) 100 years ago. For a technical example: 200 years ago, steam locomotives were the fancy new transportation tech. There's a case to be made that the successor to the successor to that tech has been on its way out for a few decades in favor of the electric locomotive.
It's pretty hard to predict what will happen in 200 years, which means we should be skeptical of both the prediction that AIs will take over by then and the prediction that they won't.
Sure maybe in 200 years we won't get AGI but current technologies that we call AI will be massively improved and I would bet by that time software development as we currently know it will be a solved problem
Not long ago, all machine tools was made by hand. When we got vastly improved CNC machines, but we still need the expertise to create the files the CNC machine needs. I'm betting that SW development will be the same. We still need engineers to understand the context the software operates in, and with that knowledge the engineer can prompt an AI to generate the first draft of the code in many small chunks that needs to be assembled.
The supply of housing on the other hand is an entirely political issue: what land can be developed, what can be built there and what public infrastructure is provided, who gets to live there - with discrimination via pricing being the main factor deciding it etc.
In the housing game, you buy land and build a house. Excluding inflation, the value of the land goes up. The value of the house goes down.
Even with regular (eg cost) maintenance, a 25 year old house is never worth what a new house is.
New building methods (just improvements in insulation alone), and things like the interior... kitchen cabinets, flooring, bathroom, means that trying to dight this is not cheap.
And even if you do? The house is still worth less than a new built.
Houses are as cars. Massive devaluation year over year.
Most don't get this, because they don't factor in inflation, nor do they factor in the cost of keeping a house maintained.
So land, land, land is the cost, which is much of what your post eludes to.
North America is filled with property, with or without a house, that is practically worthless. For example, Detroit. "Land goes up" is a narrow perspective outside of major metropolitan centres that happen to be part of the modern economy.
But certainly, where I live, rural areas.. very rural areas too, the land goes up, slowly, surely, but the houses follow the rules I originally stipulated. It's really quite a universal.
This is a very California/metropolitan-centric view.
Where I live, permits are "required" but very nearly unenforced. But it's still hard to get anything built because labour and materials.
If the "political" taps were opened tomorrow, this would be revealed in no time. It's not like we have thousands of construction workers sitting around doing nothing.
This is one of the fundamental features of traditional methods that most "construction disruptors" fail to appreciate: they are simple enough and can be done with hand tools by high-school dropouts, because the industry is forced to operate lean and can't burden itself long term with substantial fixed capital, inventory or facilities.
Regarding the unenforced permitting in your location: can I build high density European-style terraced houses, sell them to minority owners and other undesirables, and not expect the local NIMBYs to throw the law book at me? Because selective enforcement is the most toxic form of regulation with the highest risks for investors.
Depending on where you live and who’s doing the building, I’d wager you could see more enforcement. Things like skin color and socioeconomic standing definitely play into which rules are applied and to whom.
That is also quite an assumption, it could be that training on the output of better LLMs also reduces this worsening of output. There might even be a tipping point where the LLMs get good enough that training on their output is better than training on the output of humans.
And, as I understand it, one that is already demonstrably false: https://arxiv.org/abs/2306.11644
And really in reality we do have that actual problem to some degree with the presense of non-blind adults. Actual humans are a mass of mixed clued and clueless with a lot of bad input feeding output feeding other bad input around and around and around, not even counting the legitimate fair differences of opinion.
So it's a problem, but I don't think it's a fundamentally new or worse problem than we already have,and have already always had.
The fix is I don't think there is a fix for that any more than there is for the same thing in humans. There just will always be bad data feeding bad reasoning right alongside the other good data feeding good reasoning. It's probably wrong to ever expect anything else, and fail to operate from that assumption rather than the idea that there might ever be some resolution where we don't have to worry about that.
If the AIs are that good you'll just be able to ask:
- "rewrite this from scratch in a nanosecond and make sure there's zero legacy cruft"
- "oh, and btw, you're so smart and intelligent and all, certainly you'll make sure what you write is easy to understand by humans"
>- "rewrite this from scratch in a nanosecond and make sure there's zero legacy cruft"
No, that does not follow.
I'm thinking that the age of app compatibility will end in 10-20 years, and there won't be suh a thing as "old code" because it won't run at all on the new hardware or OS.
(Yes, I am sure I didn't come up with that myself but I don't know the exact quote or who came up with it.)
I was involved doing some Y2K work there because I didn't mind playing with Fortran, and part of it involved changing a year field from 2 digits to 4, because who'd have imagined their code would still be in use nearly 40 years later?
In the year 2323, browsers will still have to say "like Gecko" to maintain compatibility with websites that won't exist and no one would miss even if they remembered they existed.
So browsers are hardly even a bump yet on the cruft already accumulated.
>Institutional memory and reverse smuggling
https://web.archive.org/web/20111228105122/http://wrttn.in/0...
HN discussion from 2011: https://news.ycombinator.com/item?id=3390719
Software is extremely complex, even if it is open-source, no one except the original developers and very dedicated people will attempt to patch the myriad of issues and bugs they encounter daily. And even if we do spend the time to track down and fix a bug, there's a political and diplomatic game to convince the maintainers to incorporate your fix. It is not uncommon for a PR to just sit, unreviewed, for years. Open-source does not and will never scale, because software is orders of magnitude too complex.
Outside of software, this problem is lessened because maintainership is distributed: if your car engine breaks, you do not depend on your manufacturer to have enough time and energy to fix it. There are thousands of licensed garages that can do it for you. And, not least, the real world is much simpler than any piece of software, which is effectively completely ad-hoc: knowing how Chrome works will not help you fix this Firefox issue, whereas if you can fix the carburettor on a Honda car, you probably can do the same on a FIAT.
Open-source/distributed development and bug fixing worked much better when computers had 64 kB of RAM and programs no more than 10 pages long.
EDIT TO CLARIFY: I'm not talking of open-source vs commercial, or other types of governance. I'm talking more abstractly about the fact that having source available and open contributions does not noticeably increase the amount of bugs fixed. This comment is about software complexity and logistics of distributed bugfixing.
If ypur car's engine breaks, it's usually petty localized. Most of the time it's enough to open the hold and remove a few small parts to reach it. If your stoplight breaks, again, the scope is pretty local.
To fix or to even diagnose the issue with a tooltip in Firefox, you have to rebuild it whole, and it's about as involved and long as rebuilding a car. And even though Mozilla invented Rust to make Firefox development easier, it's far, far from just saying `cargo build`.
This raises the barrier to entry quite noticeably, even if you are an experienced software mechanic but never worked in a Mozilla-oriented garage. But even if you fixed the issue on your platform, you now have to test that the fix did not introduce a regression on at least two other major platforms (or more, depending on the component).
No wonder it's much easier to hack on smaller projects, or on projects written in JS, Python, elisp, you name it.
I think your point here is that typically with software, changing one line of code means that you need to rebuild the entire executable.
Your analogy breaks down pretty fast, though. While fixing one thing on a car _never_ requires totally rebuilding the thing from scratch, there are still tons of interlocking dependencies and architectural challenges that can impact the time/complexity required to change out a part. (See the effort required in most vehicles to change simple wear items such as a timing chain or a water pump....)
In my experience of software, most of the "rebuild pain" is self-inflicted by the project maintainers (poor automation/containerization of the build process). Software has the luxury of abstraction and automation that can reduce the build effort required from an individual in ways that a mechanic could only dream of!
But Firefox specifically, and a few other old, large, and highly multiplatform projects had more important things to do than to make building them easy, and in doing so made contributing to them harder.
It's like a Honda Civic vs some Jaguar.
Yeah this analogy doesn't make sense to me. My dad has seen head gaskets fail on multiple previous cars of his. Each time, the labour cost to replace the head gasket (a fairly cheap part) exceeded the value of the car, so he sold it to a scrapyard instead of ordering the repair.
Software does not have anything remotely analogous to this. One small bug somehow requiring you to throw out the entire codebase and start over from scratch?
> Yeah this analogy doesn't make sense to me. My dad has seen head gaskets fail on multiple previous cars of his. Each time, the labour cost to replace the head gasket (a fairly cheap part) exceeded the value of the car, so he sold it to a scrapyard instead of ordering the repair.
The key word there is labour. I change my own headgaskets.
Giving up a Sunday (which is not worth money to me) to replace the head gasket is analogous to me giving up a Sunday to track down and fix a software annoyance to me (yes, I've committed fixes to a few open source projects).
So the analogy does sorta fit, for opensource anyway.
Our issue today is that programming is too low level. We're still figuring out the standardised atomic components software of the future can be built from, but in the meantime we're rewriting the same concept, ideas and subsystem in every project. Contributing to a new project is akin to learning a new language, a new culture.
For example, compare systemd-resolved to bind or unbound.
Here’s a 2018 article explaining all the ways to configure and talk to it (back then—-it is probably more complicated now):
https://moss.sh/name-resolution-issue-systemd-resolved/
Among other things, it allocates an IP address to listen on, and both depends on and is a dependency of a decades-old standardized file that other stuff relies on.
That means it has a circular dependency with network interface bring up, and with external DNS server configuration. The article goes on for a dozen more pages explaining other issues like this.
Industry wise recalls are very much a thing, and nearly bankrupt companies in the regular. On car engines. Those are the ‘programming’ (aka design) bugs from the manufacturer.
The difference here is rather different than you’re presenting - individual cars/trucks are so expensive that one off fixes (replacing the equivalent of RAM, or a CPU, or rigging some weird combination of drives/accessories) even on really old individual machines is economic. That’s what those repair shops are doing.
also changing anything physical on a car (or even having a human of known level of knowledge verifiably look at it) is expensive and difficult to scale. And unlike computers, cars/trucks are 90% or more physical.
And while a single truck or car breaking down is localized, so is a typical PC, tablet or phone.
Computers are typically so cheap and the technology is progressing so rapidly, it’s rarely economically worthwhile to do that kind of thing. Occasionally, yes. But Certainly not at the scale cars/trucks are.
Having someone do custom work to fix the design (aka ‘fix the programming’) is relatively rare, and more of a hobbyist thing. But does happen (project cars, open source hobby projects). Though exceptions abound for simple fixes. (Which can also typically be done for individual computers through normal configuration/customization settings, or some software).
Cars and trucks are very complicated, just in ways that a techie may not recognize. Bolt patterns. Offsets. Metric vs SAE. Vacuum line levels. Metallurgy. Heat treatments. Tolerances. Hell even DC voltage levels can come into play sometimes (12v vs 24v). Vehicle communication bus type (CAN vs something else).
And working in physical parts is extremely expensive, error prone, and slow.
> And even if we do spend the time to track down and fix a bug, there's a political and diplomatic game to convince the maintainers to incorporate your fix.
That's why forking is one of the Four Freedoms. It's written into the licenses.
Granted that you need to be dedicated to even attempt to fix complex software. However, Open Source can draw from a larger pool of potential talent, and it's more likely that someone out there will care than someone in a company. What's that saying? "If you're one in a million, there's three of you in New York."?
> And, not least, the real world is much simpler than any piece of software, which is effectively completely ad-hoc: knowing how Chrome works will not help you fix this Firefox issue, whereas if you can fix the carburettor on a Honda car, you probably can do the same on a FIAT.
Aside from the difficulty of finding a carburetor on a modern car, this is about software complexity, not Open Source/closed-source per se. Fixing problems in a badly-architectured codebase is always difficult, time-consuming, and likely to introduce more bugs. Closed source doesn't make it any better.
You're focusing too much on politics, I'm focusing on Stallman wanting the source code of his printer to be available, so he could change it to better suit his needs. I'm just saying that in 2023 even if your printer is open-source, ain't nobody got time to dive into hundreds of thousands of line of code to change it.
I disagree. I disagree wholeheartedly, based on both practical projects and the retrocomputing world.
For example:
https://github.com/PDP-10/its/
This is a repo for the Incompatible Timesharing System operating system, ITS to its friends. ITS ran on 36-bit mainframe hardware from Digital Equipment Corporation (DEC) which went out of production in the 1980s. DEC was acquired by Compaq in 1998, and Compaq ceased to exist as a company in 2002. Commercially, ITS is dead. It is dead-dead. It is old-university-project-with-no-grants dead. Doornails evince more metabolic activity than ITS, at least in the commercial world. Developing on ITS means reading and writing assembly language, TECO, and a Lisp dialect that only runs on ITS and a few other OSes of similar vintage and commercial utility. However, it is still under active development because people are interested in it.
Besides: Digging into a codebase to fix a dumbass printer? People will do that out of spite. People will do that for the blog post and Hacker News thread.
But there are examples of long-time open source projects all over the place. This sounds like an argument for open source.
If you work for a for-profit company you face two different problems: overnight the company can disappear, and the IP is lost/locked forever; problems are only ever fixed if there's a profit incentive. That works, a lot, but it's not perfect either.
It's a discussion about software complexity and logistics of distributed bugfixing, not organisational.
Only full-time Firefox devs can keep an updated fork with their patches, or people paid to do so. That's the point. It's such a massive effort you can do only where and when strictly necessary. There are hundreds open-source project I interact with every single day.
If it's a design problem rather than the parts just wearing down… unless it is life threatening on a large scale, it just won't be taken care of.
As a partial workaround I started using favorites but overall v 115 is broken and can't be repaired easily. My car is still doing what it was doing last week.
[1] https://github.com/protz/Manually-Sort-Folders/issues/199
It's been a long time since I've had a new car, but from the sound of it, cars with stable feature sets are on the way toward history. Everything is fly-by-wire now, and features are increasingly implemented through software exposed through a touch screen.
It is not because cars have an inherently changeable feature set.
It's a useful skill to have when developing or using open source software, as documentation is often lacking so being able to dig in and find out for yourself quickly is valuable, but having to engage all of that encoded knowledge/constraint space every time you go to edit code is a gigantic mental burden and slows down development pace. In my time there I'd estimate my ratio of time reading code to time writing code to be at least 90:10, maybe 95:5.
What's would be fascinating is to see from the inside how massive distributed systems like Google operates evolves over a century.
Also in my experience the current generation of developers don't understand or care about useful commit history.
Still, a bugfix is always good to see.
But it can be super annoying so I'm glad to see it fixed here.
Somehow missing when you use the screenshot tool too! so very hard to send google a bug report.
Even Microsoft calls it the system tray (see as an example https://learn.microsoft.com/en-us/windows-hardware/drivers/a...)
That guy's got a problem with his entire company, and their documentation. If he can't get over it, he should clean house first and only then try to police what the rest of the world calls it. As long as MS insists that it's the system tray, people are going to call it that no matter what his team wishes it were called instead. Renaming systray.exe would be a good first step.