User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009030503 Fedora/3.0.7-1.fc10 Firefox/3.0.7 Build Identifier: If a mail server is unreachable, thunderbird causes KDE to switch desktop to its own as soon as the timeout kicks in. This is (obviously) rather disruptive if user was working on something else in a different desktop, or (worse) if he was using the machine to give a demo in a different desktop. KDE maintainers claim this is Thunderbird's fault: https://bugs.kde.org/show_bug.cgi?id=186939 I don't quite buy their argument, but just for completeness' sake, I'm also reporting the problem here. Reproducible: Always Steps to Reproduce: 1. Set up a mail account pointing to a server that doesn't exist or is unreachable (for instance, 1.2.3.4) 2. Click on that account's inbox 3. Switch to a different KDE virtual desktop 4. Wait a while until the network connection to 1.2.3.4 times out. Actual Results: As soon as the connection attempt times out, the desktop is automatically switched back to the one where Thunderbird runs on, disrupting other work that might be going on. Expected Results: Thunderbird (or KDE) should not authoritatively switch desktops on the user like that. Instead it should try to get the user's attention in a less intrusive way (such as blinking its outline in the pager). Or use the same mechanism as is used for notifying of new mails (box with info briefly flashing up and vanishing again near taskbar)

seems like this would be fixed by bug 123440

Issue also exists in Firefox (if page is shown which pops up a javascript alert())

(pinging bugs marked version 2.0) Do you also see this problem in version 3.1? http://getthunderbird.com/ If you do not, please close the bug with status set to RESOLVED and resolution set to WORKSFORME.

The problem still occurs in 3.1.6 (tested it by attempting to send a mail via a server which doesn't allow me to relay) Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6

Alain, same issue as bug 431168 ?

No. This one bug here is about Thunderbird and Firefox forcefully changing which desktop is visible and active. For example, I am editing some shell script in emacs on desktop 1, and suddenly I am placed on desktop 2 where Firefox or Thunderbird happens to run. The other bug seems to be about the "opposite" problem where Firefox would place itself on a different desktop (... and also stealing the focus...). I.e I've got kmail open on desktop 1, I click a URL contained in a mail message, and a Firefox window which used to run on desktop 2 moves to desktop 1. Both bugs are possibly related, but without a developer of that area coming online, and telling us exactly the mechanism by which Firefox causes a desktop switch (or moving its own window to another desktop), it's hard to tell whether they are the same (exact symptoms depending on some KDE setting) or different (Firefox actually calling different APIs for both behaviors). So in case of doubt, let's keep them separate, until we've got word from developers with actual experience with the relevant code.

I can't see how this could be a Thunderbird bug. AFAICS it does no manipulation of desktops whatsoever, and focuses its top-level windows in the usual way (ie, gtk_window_present, which basically just sends a _NET_ACTIVE_WINDOW message to the WM). It's entirely up to the window manager what it does with this if the application is on another desktop, and other window managers don't switch workspaces (eg, compiz sets the windows urgent hint rather than switching workspaces, which also isn't always desirable - see https://launchpad.net/bugs/808777). In reality, the window manager policy is a compromise, as there currently isn't a way for applications to provide a hint to the window manager for what the preferred behaviour should be when trying to focus a window that isn't on an active workspace (ie, should it switch workspaces? Should it move the window to the current workspace? Should it set the urgent hint on the window?). That is a limitation of the EWMH spec though, and is explained quite well here - http://blogs.gnome.org/metacity/2008/07/22/dona-nobis-pacem/ In any case, I'm not convinced that Thunderbird is doing anything wrong or unusual here.

(In reply to Chris Coulson from comment #7) > AFAICS it does no > manipulation of desktops whatsoever, good > and focuses its top-level windows in the usual way Huh? Why the hell does thunderbird feel it necessary with messing with the focus at all? This would not be quite as disruptive as pulling the desktop under the user's feet, but it is still highly obnoxious. Just imagine the user peacefully editing source code in his emacs, and suddenly, mid-sentence his keystream goes to thunderbird, causing all kinds of unintended side effects. Which is especially bad since it can happen just about any time (many people leave thunderbird up all day, and if network connection goes down during the day, it will trigger this bug). Just who comes up with these ideas, and why? http://www.codinghorror.com/blog/2007/12/please-dont-steal-my-focus.html > (ie, gtk_window_present, which basically just sends a > _NET_ACTIVE_WINDOW message to the WM). Thanks for this valuable information. Now at least we know the exact flag which triggers the obnoxious behavior, and it should be possible to talk to the KDE people to map it to something more acceptable. > It's entirely up to the window > manager what it does with this if the application is on another desktop, and > other window managers don't switch workspaces (eg, compiz sets the windows > urgent hint rather than switching workspaces, which also isn't always > desirable - see https://launchpad.net/bugs/808777). The logical reaction would be to pulse the outline in the pager, wouldn't it? I'm not familiar enough with pidgin, but at least for the Firefox situation (open a link from Thunderbird, while Firefox exists only on different desktop), there would be another solution (if the window manager allows): Firefox could _read_ the current settings (which desktop is shown? On which desktop(s) are there Firefox windows?), and if no Firefox window is on current desktop, create a new one there, with the requested web page showing. > > In reality, the window manager policy is a compromise, as there currently > isn't a way for applications to provide a hint to the window manager for > what the preferred behaviour should be when trying to focus a window that ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The problem is right there. Why does _the_application_ try to focus a window at all? Shouldn't that be the user's job to decide on which window he wants to focus his attention and keystream on? > isn't on an active workspace (ie, should it switch workspaces? Should it > move the window to the current workspace? It's amazing that such disruptive alternatives are even considered, much less implemented... > Should it set the urgent hint on the window?). If that means just visually flash it in the pager, I'm fine with that. > > That is a limitation of the EWMH spec though, and is explained quite well > here - http://blogs.gnome.org/metacity/2008/07/22/dona-nobis-pacem/ Interesting name for a web site that basically discusses whether it is more peaceful to nuke a city or to "just" firebomb it. As users, we do indeed just want to be left in peace. Don't steal focus, don't pull desktops from under us, and don't move windows to different desktops either. Well, to be fair, the article does mention an appropriate solution, but only gives it one sentence of air-time: "As a compromise, downstream Metacity has now been patched in Ubuntu, Fedora, and possibly other places to make the window demand attention when this happens (i.e. go pulsy on the taskbar)." > > In any case, I'm not convinced that Thunderbird is doing anything wrong or > unusual here. Well, it does try to steal focus, and this is wrong even without KDE escalating this into "steal desktop".

(In reply to Alain Knaff from comment #8) > (In reply to Chris Coulson from comment #7) > > AFAICS it does no > > manipulation of desktops whatsoever, > > good > > > and focuses its top-level windows in the usual way > > Huh? Why the hell does thunderbird feel it necessary with messing with the > focus at all? This would not be quite as disruptive as pulling the desktop > under the user's feet, but it is still highly obnoxious. Just imagine the > user peacefully editing source code in his emacs, and suddenly, mid-sentence > his keystream goes to thunderbird, causing all kinds of unintended side > effects. Which is especially bad since it can happen just about any time > (many people leave thunderbird up all day, and if network connection goes > down during the day, it will trigger this bug). Just who comes up with these > ideas, and why? Well, newly mapped windows are given focus by the window manager without the application requesting that (and, so they should be - imagine what your desktop would be like if the window you just opened wasn't focused). And the case you talk about is already covered by the EWMH spec (you should read about _NEW_WM_USER_TIME, see http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552314). I'm not sure why that's not working in this case, perhaps that needs some additional investigation. But _NET_WM_USER_TIME is updated by gtk based on user input, and nothing in Firefox or Thunderbird manually alters this timestamp. > > http://www.codinghorror.com/blog/2007/12/please-dont-steal-my-focus.html > > > (ie, gtk_window_present, which basically just sends a > > _NET_ACTIVE_WINDOW message to the WM). > > Thanks for this valuable information. Now at least we know the exact flag > which triggers the obnoxious behavior, and it should be possible to talk to > the KDE people to map it to something more acceptable. > > > It's entirely up to the window > > manager what it does with this if the application is on another desktop, and > > other window managers don't switch workspaces (eg, compiz sets the windows > > urgent hint rather than switching workspaces, which also isn't always > > desirable - see https://launchpad.net/bugs/808777). > > The logical reaction would be to pulse the outline in the pager, wouldn't it? Not necessarily. See the example Launchpad bug I linked. In Ubuntu, we have Thunderbird displayed in our messaging menu. Clicking on a folder entry in the menu tells Thunderbird to select the folder and focus its window. In this case, we want the workspace to change (because it was initiated by the user), but there isn't really a good way to tell the window manager this, so we are stuck with a compromise which sucks (ie, the WM setting the urgent hint instead). > > I'm not familiar enough with pidgin, but at least for the Firefox situation > (open a link from Thunderbird, while Firefox exists only on different > desktop), there would be another solution (if the window manager allows): > Firefox could _read_ the current settings (which desktop is shown? On which > desktop(s) are there Firefox windows?), and if no Firefox window is on > current desktop, create a new one there, with the requested web page showing. > No, that would be awful. I want all my Firefox tabs in one window. I don't want all my tabs scattered across different windows on different desktops > > > > In reality, the window manager policy is a compromise, as there currently > > isn't a way for applications to provide a hint to the window manager for > > what the preferred behaviour should be when trying to focus a window that > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > The problem is right there. Why does _the_application_ try to focus a window > at all? Shouldn't that be the user's job to decide on which window he wants > to focus his attention and keystream on? > No, the problem is not right there. The window manager decides whether to give focus to a newly mapped window (or an existing window requesting focus), based on the values of _NEW_WM_USER_TIME on the window requesting focus and the currently active window. This is designed to prevent windows stealing focus if you are working on something else (see the link above). > > isn't on an active workspace (ie, should it switch workspaces? Should it > > move the window to the current workspace? > > It's amazing that such disruptive alternatives are even considered, much > less implemented... > I already gave an example above as to why such "disruptive" alternatives are necessary. > > Should it set the urgent hint on the window?). > > If that means just visually flash it in the pager, I'm fine with that. > > > > > That is a limitation of the EWMH spec though, and is explained quite well > > here - http://blogs.gnome.org/metacity/2008/07/22/dona-nobis-pacem/ > > Interesting name for a web site that basically discusses whether it is more > peaceful to nuke a city or to "just" firebomb it. As users, we do indeed > just want to be left in peace. Don't steal focus, don't pull desktops from > under us, and don't move windows to different desktops either. > > Well, to be fair, the article does mention an appropriate solution, but only > gives it one sentence of air-time: "As a compromise, downstream Metacity has > now been patched in Ubuntu, Fedora, and possibly other places to make the > window demand attention when this happens (i.e. go pulsy on the taskbar)." > > > > > In any case, I'm not convinced that Thunderbird is doing anything wrong or > > unusual here. > > Well, it does try to steal focus, and this is wrong even without KDE > escalating this into "steal desktop".

(In reply to Chris Coulson from comment #9) > Well, newly mapped windows are given focus by the window manager without the > application requesting that Well, actually, most newly mapped windows aren't given focus (as can be tested quite easily using sleep 2; konsole , and going to work in some other window: when konsole pops up, it doesn't automatically grab focus, even with KDE "focus stealing prevention" off). > (and, so they should be - imagine what your > desktop would be like if the window you just opened wasn't focused). I'm at a loss here... most apps don't fortunately do this, and the world hasn't ended yet... so what grievous consequences are you thinking should have happened? > And the case you talk about is already covered by the EWMH spec (you should > read about _NEW_WM_USER_TIME, see > http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552314). I'm > not sure why that's not working in this case, perhaps that needs some > additional investigation. But _NET_WM_USER_TIME is updated by gtk based on > user input, and nothing in Firefox or Thunderbird manually alters this > timestamp. Good idea, but apparently this is not honored by all window managers. Besides, what would this value be for newly launched apps who haven't yet interacted with the user? > Not necessarily. See the example Launchpad bug I linked. In Ubuntu, we have > Thunderbird displayed in our messaging menu. Clicking on a folder entry in > the menu tells Thunderbird to select the folder and focus its window. I use Kubuntu (KDE), and never heard about this messaging menu. What is it supposed to do? > In > this case, we want the workspace to change (because it was initiated by the > user), but there isn't really a good way to tell the window manager this, so > we are stuck with a compromise which sucks (ie, the WM setting the urgent > hint instead). Would it have been feasible to introduce a new WM setting for this special purpose? Indeed, changing semantics of existing WM settings seems rather dangerous to me, as it impacts unwitting existing apps, which rely on the old semantics... Strange that nobody seemed to consider this (IMHO) rather obvious risk... > > Firefox could _read_ the current settings (which desktop is shown? On which > > desktop(s) are there Firefox windows?), and if no Firefox window is on > > current desktop, create a new one there, with the requested web page showing. > > > > No, that would be awful. I want all my Firefox tabs in one window. I don't > want all my tabs scattered across different windows on different desktops Maybe have a configuration setting? If I remember correctly, we already have the choice between 2 behaviors: (1) "open link in new tab" and (2) "open link in new window". So we'd introduce (3) "open link in new tab if window present on current desktop, and in new window otherwise". That way each could have his preferred behavior. > No, the problem is not right there. The window manager decides whether to > give focus to a newly mapped window (or an existing window requesting > focus), based on the values of _NEW_WM_USER_TIME on the window requesting > focus and the currently active window. This is designed to prevent windows > stealing focus if you are working on something else (see the link above). ... and apparently, this is not working in all cases ... Wouldn't it be easier to forbid focus stealing globally, and only whitelist the handful of "legitimate" apps that may do it (pagers, messaging menues, some docks...). Yes, apps could still forge their window or app name, but that would clearly establish maliciousness.

nagging voice (still) says this a duplicate

If this is indeed a duplicate, can anybody quote the id number of the bug it duplicates?

(In reply to Alain Knaff from comment #12) > If this is indeed a duplicate, can anybody quote the id number of the bug it > duplicates? really, search bugzilla isn't that difficult. Click "edit search" at bottom to modify this example - https://bugzilla.mozilla.org/buglist.cgi?f1=OP&o3=anywordssubstr&list_id=6869476&v3=kde&resolution=---&classification=Client%20Software&classification=Components&o2=allwordssubstr&f4=CP&query_format=advanced&j1=OR&f3=short_desc&f2=short_desc&v2=virtual%20desktop&product=Core&product=Firefox

much better starting example (changed to KDE as a word rather than string) https://bugzilla.mozilla.org/buglist.cgi?f1=OP&o3=anywords&list_id=6869544&v3=kde&resolution=---&classification=Client%20Software&classification=Components&o2=allwordssubstr&f4=CP&query_format=advanced&j1=OR&f3=short_desc&f2=short_desc&v2=virtual%20desktop&product=Core&product=Firefox

Walt, any wisdom regarding current version?

I no longer use the KDE desktop.

Testing Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 on Kubuntu 16.04 in Desktop 1 with a misspelling in my POP accounts server address I never get a timeout. With a misspelling in my IMAP accounts server address I see a timeout notification in Activity Manager, but the focus remained on Firefox in Desktop 2.