I've also noticed the same problem with other applications.  For example:

Open a message in a separate window in thunderbird.
Raise the main window over the top of it.
Double click the same message again, and thunderbird will raise the original window for you to work in.

Now repeat the process with raise_on_click disabled.  Thunderbird will not be able to raise the window.  If the message window were completely obscured by the main window, I can imagine this causing considerable confusion to users, because it will feel as though the application has stopped working.

* applications are prevented under metacity from raising their own windows unless they happen to be the active application (see bug 166395 and patch 37051)

* an attempt to do so will at most set the attention flag, if any part of the window was obscured, and at least do nothing (see bug 305882)

* the exception is with override-redirect windows, which are unmanaged and therefore metacity can't do anything about them anyway (see bug 154529)

This needs to be in an FAQ or something, maybe.

I don't clearly remember what the rationale is for this. The code says "this is broken behaviour", so presumably there's a pretty good reason somewhere. I expect someone will be along in a moment to explain.

(the "this" in "this is broken behaviour" is the attempt to restack windows, not metacity's policy about it.)

here's the source:
http://svn.gnome.org/viewcvs/metacity/trunk/src/window.c?annotate=3222#4512

See also Havoc's comment above it:

/* Only a very
* few clients even require the raise/lower (and in fact all client
* attempts to deal with stacking order are essentially broken,
* since they have no idea what other clients are involved or how
* the stack looks).
*/

(In reply to comment #2)
> * applications are prevented under metacity from raising their own windows
> unless they happen to be the active application (see bug 166395 and patch
> 37051 [edit])

I understand that.  I think you may have misunderstood this bug report.  In this case, this application *is* the active application, but the window still isn't raised.

The behaviour is correct, if you have raise_on_click set.  But if raise_on_click is not set, the window doesn't raise, even if it's the active application.

The test case script I gave is just that, a test.  We saw this in a real application, and if you really don't think this is a bug, then I'd like a suggestion as to how the application developer should get around this problem:

1)  The user selects a menu option, which creates a new modeless dialog window.  There should only be one of these at a time.

2)  The user minimises or lowers the dialog, and forgets about it.

3)  The user selects the menu item again, next time they want the dialog.  Rather than opening the dialog afresh, the Tk application uses 'wm raise' to bring the pre-existing window to the front (deiconifying it if necessary).  This is fairly normal behaviour, and lots of applications on e.g. Windows and Mac OS X behave that way.  It's what most users expect, and it works on metacity too, except for this one case, if the user doesn't have raise_on_click set.

Regards,

Tim

Oh, I'm sorry, I missed that this was the active application. Mea culpa. Reopening and adding to http://live.gnome.org/ThomasThurman .

A short sidetrack (unrelated to the bug, but perhaps useful nonetheless):

In general XRaiseWindow sucks for "activating" a window (activation entails a _lot_ more than raising; it could mean focusing, deiconifying, unshading, switching workspaces, scrolling the viewport, rotating it from it's three dimensional sideways orientation so that the user can view it, and perhaps other steps not yet invented in current window managers).  If you want to activate a window, you should use the _NET_ACTIVE_WINDOW message from the EWMH rather than attempting to do as many "activation" steps on your own as you know how.


Okay, back to the bug:

Any change to the behavior of raise_on_click would either mean that the feature doesn't work right, or that application developers have to modify their apps to deal with the complexity of additional WM possibilities.  Having the feature not work right would mean we may as well remove it.  Placing additional requirements on app developers seems to have been too onerous even in the case of the option for click-to-focus versus mouse-focus; and that is an option that has orders of magnitude more users.  In my opinion, we either remove the option entirely, or leave it as it is.  No more complexity for app developers.

I think the right fix is to simply update the description of this feature in hopes that people quit misusing it.  Here's my patch to do so:

Index: src/metacity.schemas.in
===================================================================
--- src/metacity.schemas.in     (revision 3233)
+++ src/metacity.schemas.in     (working copy)
@@ -93,14 +93,28 @@
          <short>Whether raising should be a side-effect of other user
                 interactions</short>
          <long>
+           Setting this option to false can lead to buggy behavior, so
+           users are strongly discouraged from changing it from the default
+           of true.
+
            Many actions (e.g. clicking in the client area, moving or
            resizing the window) normally raise the window as a
            side-effect. Set this option to false to decouple raising from
            other user actions.  Even when this option is false, windows can
            still be raised by an alt-left-click anywhere on the window, a
-           normal click on the window decorations, or by special messages,
-           such as activation requests from pagers. This option is
-           currently disabled in click-to-focus mode.
+           normal click on the window decorations, or by special messages
+           from pagers, such as activation requests from tasklist applets.
+           This option is currently disabled in click-to-focus mode.
+
+           Note that the list of ways to raise windows when raise_on_click
+           is false does not include programmatic requests from
+           applications to raise windows; such requests will be ignored
+           regardless of the reason for the request.  If you are an
+           application developer and have a user complaining that your
+           application does not work with this setting disabled, tell them
+           it is _their_ fault for breaking their window manager and that
+           they need to change this option back to true or live with the
+           "bug" they requested.
          </long>

I believe this *is* a genuine bug which can be fixed.

raise_on_click should control whether the WM raises a window that is not at the top when clicked. However, it should not prevent apps from raising themselves.

I assume that it is the WM that raises the application when it is clicked and the application doesn't check for clicks and raise itself?

It seems to me as if the issue is that this option has been implemented by disabling the raise call somewhere along the pipeline. Therefore the solution is simply to send the click to the window without ever raising it, rather than by disabling the raise functionality so that it doesn't happen when called.

I am probably making some incorrect assumptions as I am not familiar with gnome code so please explain if I'm wrong about this.

I also think there are some related features that could be implemented:
raise_on_move - currently always raises
raise_on_resize - currently always raises
raise_on_tap - by this I mean if you click and release the title bar or border (without dragging that would cause a move or resize), as some users may want to be able to raise the window this way even when the other raise methods are disabled.

(In reply to comment #7)
> raise_on_click should control whether the WM raises a window that is not at the
> top when clicked. However, it should not prevent apps from raising themselves.

Apps can't raise themselves.  They can only ask the WM to raise them.

> I assume that it is the WM that raises the application when it is clicked and
> the application doesn't check for clicks and raise itself?

Yes.

> It seems to me as if the issue is that this option has been implemented by
> disabling the raise call somewhere along the pipeline. Therefore the solution
> is simply to send the click to the window without ever raising it, rather than
> by disabling the raise functionality so that it doesn't happen when called.

Don't we currently send the click to the window without ever raising it?  I thought we did.

> I also think there are some related features that could be implemented:
> raise_on_move - currently always raises
> raise_on_resize - currently always raises
> raise_on_tap - by this I mean if you click and release the title bar or border
> (without dragging that would cause a move or resize), as some users may want to
> be able to raise the window this way even when the other raise methods are
> disabled.

raise_on_click is currently a minefield of confusion; I don't want to make it four times worse.

This is still a horrible misfeature from a users perspective, and should be completely removed if it can't be made to work properly.

I've used other window managers that get it "right" (at least as expected by the user):
Clicking on a window ONLY sends the button event to the application.  No WM interaction.
alt-clicking (or the WM's equivalent binding) raises the window without sending a button event to the application.
Applications can notify the WM that a specific window should be focused - for instance in pidgin, clicking on the buddy list for an already existing IM conversation brings that conversation to the front.   

It really feels like the metacity behavior here is a botched hack in the wrong place.  There's already a "if clicking on an obscured window, raise it" test, just add "unless the user disabled that feature" rather then hacking around somewhere completely different and screwing with the active application requesting a sub-window be brought to the front.

The lack of this feature bugs me daily, when trying to cut-and-paste between different apps that all request enormous amounts of screen realestate to be able to get to their controls.  I can generally layer them over each other so that the appropriate inputs are all accessable, but with raise-on-click it's constantly obscuring another one. 

I am not a WM developer but I do use the advanced configuration options and I care a lot about how my WM behaves. These features have a real impact on usability.

Just about the first thing I do with Metacity is turn off raise_on_click.  As Dan points out, having a window pop to the top of the z-order every time you interact with it is a nuisance when screen real estate is limited.  You want to be able to layer the windows to expose the relevant controls and not have them get shuffled as you work.  A few years ago I used to hack and recompile Metacity to keep it from doing that; being able to fix it using gconf-editor is nice.  Nicer still would be a checkbox next to the "focus follows mouse" option in its control panel.

Though I must admit I don't really know what I'm talking about here, what Dan says in his 3rd paragraph above seems to make a lot of sense.  I don't see why keeping the WM from changing the z-order on a click has to prevent the WM from honoring raise requests from the programs themselves, unless it's common for programs to issue raise requests every time they receive a click.

The behavior here isn't due to a hack, it's just a sort of incidental effect of other decisions. 

* metacity always ignores raise requests.
* metacity does allow activate requests (_NET_ACTIVE_WINDOW) but super old stuff like Tk won't use that.
* when you click a window, metacity activates it.
* when metacity activates a window, it raises it, unless raise_on_click=false.

So really the config option is raise_on_activate, not raise_on_click. raise_on_click controls whether activation raises. The pref has nothing to do with handling of raise requests coming from the app; those are simply always ignored.

The problem with Tk is that it's trying to raise, instead of trying to activate.

The problems with other apps could be that, or could be that other hints or design decisions in the apps are wrong, it depends on the specific scenario.

The special-case hack would be to allow raise requests from apps when raise_on_click=false, because in that mode we don't care about the invariant that activated implies topmost. But this would mean that apps written for raise_on_click=false would have special-case code and different behavior only for that WM configuration. Seems like a bad solution. But not knowing specific scenarios, who knows.

Basically, the hunk of Elijah's original patch:

@@ -4217,7 +4222,8 @@ meta_window_configure_request (MetaWindow *window,
     {
       MetaWindow *active_window;
       active_window = window->display->expected_focus_window;
-      if (meta_prefs_get_disable_workarounds ())
+      if (meta_prefs_get_disable_workarounds () ||
+          !meta_prefs_get_raise_on_click ())
         {
           meta_topic (META_DEBUG_STACK,
                       "%s sent an xconfigure stacking request; this is "

doens't make sense to me, whether added to the docs, as in comment 6, or not.

Metacity *does* normally allow certain stacking requests from clients to be honored; this seems unrelated to the raise_on_click setting unless you think that the normal reason that apps use stacking requests is to manually implement a raise-on-click behavior, which seems unlikely.

Reopening the bug since despite all the discussion, I don't see an indication of why that test was added or why it should have be added.

I just want to echo what Chris Koresko wrote.  Please don't eliminate the ability to turn off raise_on_click.

Created attachment 147996 [details] [review]
Allow applications to raise windows when raise_on_click is off

Here's the obvious patch I'm applying to the Fedora and RHEL packages.

Review of attachment 147996 [details] [review]:

This still applies cleanly.

It looks on the reasonable side, but appears to be contrary to Havoc's suggestions earlier.  So I'm a bit nervous about merging it. Owen: can you tell me whether this ever made its way into Mutter?

Yes, we landed it in Mutter a while ago. Think this was just some accidental misinterpretation of what Havoc was saying - see what I said in comment 12, etc.

Review of attachment 147996 [details] [review]:

Committed, then.

-> FIXED

When digging down to disable "raise-on-click", I see:

"If you are an application developer and have a user complaining that your application does not work with this setting disabled, tell them it is -their- fault for breaking their window manager and that they need to change this option back to true or live with the "bug" they requested."

This comes across as a little aggravating and doesn't appreciate the need for this feature for some users and somehow suggests they are trouble causers by asking for things that get in the way of bug free software.

It's been mentioned by couple of posters, but this feature can be fairly critical to a number of applications. Linux has been the primary OS on the desktop side of the Visual Effects industry for 12-15 years now, taking over from SGI workstations which exhibited this windows behaviour (that is not raising on click). Consequently, many applications on that side are designed with a floating window "mentality", what you are close to enforcing here is a MS Windows/OSX window management that can cause a lot frustration when working with a large number of floating windows.

I'd like to see a little more open mindedness in this corner, surely one of the attractions of Linux is the "Openness"? OK, so the majority of users will find windows not raising on click to be a little confusing, but please try to be a bit more accommodating with those who have need for it. The language used makes me think I wont be able to turn it off in some coming release and that's scary enough for me to make me think I should be using another distro and I quite like Ubuntu in almost every other respect.

DanS says it more eloquently than I could hope for, but suppressing raise-on-click is one of my main productivity boosters as a staple of my day-to-day workflow - professionally and personally.

Even trying to contain myself, I do seem to get the distinct feeling that GNOME is trying its darndest to introduce all the features that pushed me away from Windows back in 1998, and removing all the features that I have come to love for being so very much better than what I left behind.

Case in point: disabling raise-on-click is no longer a selectable option in any configuration manager save for regedit.exe^H^H^H^H^H^H^H^H^H^H^H gconf-editor.

Do you guys really hate the *nix heritage so much that you will throw it all to the wind for the sake of (poorly) emulating the "sacred" MS/Apple UX?

Have you no values of your own save for trying to lower the hitherto lowest common denominator?

Seriously?

It seems that something has become worse in gnome-3.14. I've been using gnome without raise-on-click just fine up to gnome-3.12 on Debian/unstable, but now with gnome-3.14 when I turn off raise-on-click, I can no longer raise the window with <Super>click. Ideally I would like <super>left-click to raise, but now it will only raise if I also move. Also title bar or decoration click no longer raises the window if raise-on-click is off, these all used to work in gnome-3.12. I can still use key bindings to raise, but I'm quite used to the mouse for this.

Zoltan, please open new bug report and include following info:
1) What metacity version are you using (apt-cache policy metacity)?
2) Steps how to reproduce bug. I have never turned off raise-on-click so I don't know how it should work.
3) What session are you using? GNOME use mutter these days not metacity.

You are right, ignore this please. I was mislead by the chastising comment in dconf-editor under org.gnome.desktop.wm.preferences raise-on-click which has referred to this bugzilla entry. Sorry for the trouble!