392721 - Invalid usage of _NET_ACTIVE_WINDOW in response to remote URL-load requests

Status: RESOLVED DUPLICATE of bug 721498

(Toolkit :: Startup and Profile System, defect)

Description

[Martijn Wargers (dead)]

This came from a Hendrix report. I don't really know what it is about, but looking at the post, I think he/she knows what he/she is talking about.

"
 The _NET_ACTIVE_WINDOW request (to make the window
active) is using an old timestamp when you click a
link in another program and it opens in Gran
Paradiso.  The timestamp it is using, is the time
the user last used the Gran Paradiso window.  The
timestamp it _should_ be using the time that the
user clicked the link in the other program and
launched it in Gran Paradiso (this is available from
startup notification) - or as a last resort the
current server time when Gran Paradiso received the
request to open the link

Additionally, when the window manager supports
_NET_ACTIVE_WINDOW, using a ConfigureRequest to
raise the window is not only redundant but extremely
rude.  Depending what the user is doing, the Gran
Paradiso window may not be activated immediately.

Browser Details: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a7) Gecko/2007080209 GranParadiso/3.0a7 
"

I see one mention of the term _NET_ACTIVE_WINDOW in the source:
http://lxr.mozilla.org/seamonkey/source/toolkit/components/remote/nsGTKRemoteService.cpp#307
That code was added with bug 223492.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

CCing people who may be interested in fixing this bug (although I don't know what the priority should be because it's not clear how serious it is)

Comment 2

[Mike Hommey [:glandium]]

This is probably related, but metacity prints the following messages when launching iceweasel/firefox:
Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x36000ca (Iceweasel )
Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed.

Comment 3

[Mike Hommey [:glandium]]

Note it does so only when launched from command-line, which is probably why it triggers this code "protected" by desktopStartupID.IsEmpty().

http://lxr.mozilla.org/mozilla/source/widget/src/gtk2/nsWindow.cpp#728

Comment 4

[Greg Fitzgerald]

This is defiantly annoying using any window manager following this standard correctly. Currently using Openbox and anytime I click a link in my feed reader firefox is switching desktops. Would love to see this fixed.

Comment 5

[Toni Spets]

Seconding Greg, it is a problem that firefox sends this message.

For example opening a link from another program that opens in firefox will move the firefox window to current desktop when using standards compliant window managers like Openbox.

For those who suffer from this there is a workaround:
from about:config set browser.tabs.loadDivertedInBackground to true

If someone really wants this it should be configurable and not the default.

Any comments on this from the developers? The Openbox team says it's a problem with the software that sends it and its not the window managers job to workaround it.

Related bug report submitted by me for Openbox:
http://bugzilla.icculus.org/show_bug.cgi?id=3659

I don't know the inner works of X system or window managers so I can't comment on whos fault it is, just an annoyed user.

Comment 6

[Serge Gautherie (:sgautherie)]

(In reply to comment #0)

> That code was added with bug 223492.

Bug 223492 comment 51
[
From  Colin Walters   2007-10-19 12:09:40 PDT

I wanted to comment on this bug; we integrated this patch for Fedora 8, and a
bit of a tempest in a teapot has resulted.

The primary issue seems to be that for people using multiple workspaces on
Linux, popular window managers such as Metacity and Compiz do not behave as
these people would like.  In a single workspace case, this patch creates the
expected effect that clicking on a link will show that link.  I see no issue
there, and most people seem to not disagree.

Metacity: https://bugzilla.redhat.com/show_bug.cgi?id=307581
Compiz: https://bugzilla.redhat.com/show_bug.cgi?id=339711
Upstream Metacity: http://bugzilla.gnome.org/show_bug.cgi?id=482354

Executive summary here is that I think the Firefox patch is basically correct
(though Bill pointed out some potential issues I'm going to investigate), but
Firefox may be blamed for the change when the conclusion seems to be this is a
window manager issue, so I wanted to comment here.
]


***

(Just wondering if this could be related to some of the intermittent focus failures some tests report (on Linux) ?)

Comment 8

[Karl Tomlinson (:karlt)]

(In reply to comment #0)
> Additionally, when the window manager supports
> _NET_ACTIVE_WINDOW, using a ConfigureRequest to
> raise the window is not only redundant but extremely
> rude. 

I expect that is a result of gtk_window_present_with_time using gdk_window_show (instead of gdk_window_show_unraised) before calling gdk_window_focus.

Comment 9

[Karl Tomlinson (:karlt)]

(In reply to Mike Hommey [:glandium] from comment #2)
> This is probably related, but metacity prints the following messages when
> launching iceweasel/firefox:
> Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with
> a timestamp of 0 for 0x36000ca (Iceweasel )
> Window manager warning: meta_window_activate called by a pager with a 0
> timestamp; the pager needs to be fixed.

(In reply to Mike Hommey [:glandium] from comment #3)
> Note it does so only when launched from command-line,

This is tracked in bug 449723.

Comment 10

[Karl Tomlinson (:karlt)]

(In reply to Greg Fitzgerald from comment #4)
> This is defiantly annoying using any window manager following this standard
> correctly. Currently using Openbox and anytime I click a link in my feed
> reader firefox is switching desktops. Would love to see this fixed.

This is a different issue to that reported in comment 0.  Better track this in a separate bug.  Comment 6 is concluding that this is a window manager issue, but
perhaps ideally the app should only reuse an existing window that is on the current desktop.

Comment 11

[Karl Tomlinson (:karlt)]

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #0)
> "
>  The _NET_ACTIVE_WINDOW request (to make the window
> active) is using an old timestamp when you click a
> link in another program and it opens in Gran
> Paradiso.  The timestamp it is using, is the time
> the user last used the Gran Paradiso window.  The
> timestamp it _should_ be using the time that the
> user clicked the link in the other program and
> launched it in Gran Paradiso (this is available from
> startup notification) - or as a last resort the
> current server time when Gran Paradiso received the
> request to open the link

There is a patch in bug 721498 to fix this, so duping forward to there.