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.
(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 see this on a daily basis, Most times multiple times a day on a Linux KDE Plasma system with it installed natively on OpenSuse Tumbleweed. Best i could describe it is that it happens when i happen to switch to another virtual desktop using keyboard shortcuts on the exact same frame that the tool tip pops up. My guess is it was some kind of race condition that required very precise timing that made it difficult to narrow down, Paired with heavy use of keyboard shortcuts meaning alot of people likely were not effected by it. Very glad to hear it has been fixed and looking forward to getting a version of Firefox with it!
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.
I believe this is a common enough bug for many GUI systems. For example I have seen this behavior a lot from Windows 10 taskbars; the only way out was to hover the cursor on top of multi-window button and then out of the taskbar. A lot of websites also have a similar issue with a right condition.
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.
Hm, is that assumption correct? I don't know about Windows, but on Linux/X11, app windows do get mouse-enter/move/leave events even if they are not focused.
This is highly specific to toolkits, but windows in Windows (wink) do not receive mouse events unless they are configured to "capture" mouse events (`SetCapture`). And even when there exist APIs for them, the existence of faulty websites suggests that the easiest path is probably incorrect anyway.
The Devil is in the details. And in the case of the X11 Devil, they're literally named "detail", and they sound weird enough for Elon Musk to name his children after.
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;
More details (these are just the "normal" ones, just wait till you read about "abnormal" NotifyGrab and NotifyUngrab mode and input focus events, and how grabbing interacts with input focus, and key map state notifications):
>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:
The tray menu of Steam (and a few other apps) has a similar problem where the menu gets stuck. Likewise, this hasn't been fixed in around 15 years, probably more.
Perfectly synchronized input event delivery across all applications was one of the strong and important guarantees that the NeWS window system was designed from the ground up to provide (from since it was originally called "SunDew" in 1985).
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":
>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 ...
I think about what could have been, how it should work, whether we could fix this, every time I go to click or touch or type and the system I’m using directs my input to somewhere other than I intended.
I experienced the bug a lot when interacting with YouTube video embeds on other web pages. It goes like: hover cursor over the embedded player's full screen control, "Full screen (f)" tooltip appears, click control, video goes full screen but tooltip remains over top of playing video.
It's a very workflow-specific bug. I pretty much only encounter it while playing video games.
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.
It's the same thing with games - whenever a game from a studio known for "broken" titles comes out, people post compilations of strange things happening, and it just never happens on my end. Natural bug resistance, perhaps.
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.
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.
Imagine how much money Mozilla could have made over the last 22 years if only they'd sold ad space in the stuck tooltip! They should monetized their own bugs, before somebody else does.
Yeah this happens a lot when the DOM changes and the app loses the track of the tooltip so it can no longer dispose of it when you navigate away from the target.
Yep. Trivial to trigger this in chrome with gmail, hoverovers persist in a tooltip like box no matter how much scrolling you do. If you can make ANOTHER one pop up the first dies and if you want, you've now put the thing into its correct handler loop and the one you trigger dies too.
Somehow missing when you use the screenshot tool too! so very hard to send google a bug report.
There was a similar Windows bug when a tooltip in the notification area (systray) wouldn't disappear no matter what. I first found the bug in Windows XP, and then witnessed it in Vista, in Windows 7, Windows 10. It was my ritual to check if it's fixed yet when upgrading to a new version of Windows. It never was. Since then I moved to Linux and now I don't know if it's fixed or not.
According to the article, systray.exe puts some icons into the notification area. Somewhat akin to calling a bus stop Lee because Lee uses that bus stop?
A thing about language is that nobody controls it, not even Microsoft, if everyone calls it the System Tray as they have done for 30 years, it is the System Tray.
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.
Same, although I haven't seen this one for a while now. One way to fix the misbehaving explorer (which start menu, tray and others are part of) is to simply kill it and start it over from the task manager. Some applications failed to re-create their tray icons after this, but either all of them fixed it, or it got somehow fixed in Windows.
This still happens on my Windows 11 machines (the tooltip stays there unless you move the mouse over the same icon again), but only to a small number of applications. Makes me wonder if they are using a different set of API to set up their tray icons.
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...
It's a common motif in desktop videogaming. The modern desktop computing model is a multitask windowed architecture where the mouse controls the cursor on the screen, a focused window receives events, and the keyboard generates events that may or may not translate to filling text buffers or activating behaviors based upon the subtle state of the concept of "focus."
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.
There's countless people who have screamed that they want to switch from chrome, but can't because profiles don't work the way we want them too. And it's two seemingly small changes that need to happen too.
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.
And, if I remember correctly, the whole Profile things was initially hidden in Firefox. I remember you couldn't easily switch profile without using the command line.
Yes, it was there, but not really supported. We had to (ab)use the feature for some stuff, but everything was read-only and locked down by enterprise profiles, so it was not a big problem for us.
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 reboots are so sexy though -- if this is like any company I've been involved with, they hire/promote a new design boss every couple years, and that person spends 6 months making a sexy Illustrator/Sketch/Figma (in that order over the years) document showing how hott things would look if we changed all the fonts and aped whatever widgets had been redone in last year's iOS. Instant greenlight. Try getting that kind of C-suite buy-in for a boring under-the-hood fix!
I'm using Firefox on Linux and 2 is how it's been working for me for a looong time now. Clicked links in external programs always open in the last active Firefox window for me. Is this OS or even window-manager specific?
I think they mean they have windows open in different profiles (profiles, not containers), and want the last active one to pick up links from external apps...
I, for one, would like the last active container to be used.
Interesting. I like the option which Edge gives, which is I select the profile that gets URL opens from outside the browser (my "main work profile") and add site-level exceptions that route certain sites to the right profiles (example: LinkedIn links should open in my personal profile, Demo Server accounts open in the dedicated demo profile).
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.
Yeah, I can see how that can end up messy, but filtering by url also doesn't always work. To give one example: I may open google docs in different containers because I have several accounts (personal and work). So, if I receive a link to a doc that was shared to me, and open it from the mail client... it won't necessarily end up in the right container. It can end up working fine when you use the menu to open in another container, but on many sites, the original url is redirected to a login page or whatever and opening in another container is not going to be helpful at all because you've now lost the original link you needed to open.
Are you using different profiles ? I have two running at the same time, links always open in the browser instance running the "default" profile, not the other one.
i also have two profiles. i noticed that for me links open in the profile that was started last. in my case i always want them to open in the default profile, so i have to make sure to start the other profile first, and default second.
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.
> at that point it can't even know which process has the last active window. it would have to connect to both processes
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.'
i don't know how wayland does it, but one of the challenges in X11 was that it was not trivial or even possible to relate an X11 window to its unix process because the window could be coming from a remote machine. in other words X11 knows nothing about unix processes.
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.
I got tired of dealing with it and just told my system that URLs should be opened by a script I wrote that just puts the URL in the clipboard and shows a notification that it did so. So I open/click a link, then go find the window I want it to open in and paste and go.
Containers are enough for your use case. I know that for some usage cases, are enough. But for nearly 90% users, they are enough and even better that profiles.
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"
This is exactly the reply I was expecting. The "yes it works but here's some extra things you need to do to make it work". No average user is going to do that.
Last week I was at a project meeting cum conference, where most people attending were scientists, but not computer people. They have showed what they did with computers and programming languages, and it amazed me with no end.
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.
I remember commenting with a "me too + info" on a bug years and years ago and finally stopped using Firefox for good about a decade ago mostly because this bug had been annoying me multiple times a day for years and Chrome was finally good enough to replace 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.
- 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;
If I see correctly, all the changes are:
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;
now it's:
if (!b)
return OK;
X;
return OK;
which in this case increases readability as X is in many lines and b is a more complex condition.
Can any one give a brief synopsis of the state of XUL and gecko in Firefox/Mozilla? Are the XUL (XULRunner) and gecko runtimes still actively worked on? Or has it been absorbed into the Firefox runtime long ago?
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 you look closely, you'll see that it's not merely an indentation change. The bulk of the function used to be inside a large condition, but that has been changed to an early return. Still, it would have been a little nicer if it had been done in two commits.
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.
i always struggle with this. i usually end up with code changes first because i want to test code before committing, which means i can't commit a whitespace change before i know the code change works.
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.
Linus Torvalds would like a word with you. If something is changed in the kernel, even if it's technically a bugfix and something in userspace breaks, it's a kernel bug, period.
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?
Issues for unsupported platforms would be closed (RESOLVED WONTFIX) but they wouldn’t be deleted. Bugzilla’s default search songs only return open bugs. Here’s a search for all bugs with OS = “BeOS”. Maybe one of them is your bug?
Oh god, finally. A related bug, https://bugzilla.mozilla.org/show_bug.cgi?id=1569439 , was closed 9 months ago, and that made things slightly 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.
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.
The malloc design, that led to that yacc bug being discovered, seems to have another interesting property which I didn't see discussed there:
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.
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.
I see it a lot with Windows Explorer and Microsoft Word, never with Firefox, even though I use all of them daily on my work laptop. It seems people have so different usage patterns that they see completely different bugs...
It's pretty easy to see why this behavior can come from programs that's don't use any standard OS toolkits, but go for custom or cross-platform solutions:
- 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...
A sane method for websites to indicate if a password worked or not. And for enough websites to use it that password saving heuristics could be disabled.
When you submit a form with a password and the password is wrong, you're usually taken back to the same form with the same password. The browser is showing you a form that, if it were submitted, would update the same saved password. Yet the popup dialog asking you whether you want to save the previous obviously wrong value is still persisting.
But you can store only one not-working password per username and website. Clearly it should support multiple passwords for the same username and website and have a flag "working" or "not working". Bugmenot has this all figured out years ago!
(Also, your username triggers me in a wildcard sort of way.)
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 was a bug in the Gecko engine, which was used in Netscape 6 and the Mozilla Suite (Navigator and Communicator) before Firefox was created (in response to Mozilla Suite bloat). Gecko still uses the same Bugzilla bug tracker.
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.
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.
It's definitely one of those things that can drive someone a little crazy.
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.
346 comments
[ 0.24 ms ] story [ 309 ms ] thread(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/
More details (these are just the "normal" ones, just wait till you read about "abnormal" NotifyGrab and NotifyUngrab mode and input focus events, and how grabbing interacts with input focus, and key map state notifications):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:
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 ...
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.
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.
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...
https://www.youtube.com/watch?v=ZSRHeXYDLko&t=2729s
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] https://bugzilla.mozilla.org/show_bug.cgi?id=1479858
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.
https://github.com/johnste/finicky
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.
Especially true if breakpoints don't work :)
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:
now it's: which in this case increases readability as X is in many lines and b is a more complex condition.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
https://mzl.la/3twxg9n
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.
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.
- 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...
https://xkcd.com/1172/
(Also, your username triggers me in a wildcard sort of way.)
Bug is fixed, please retest :)
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.