Comment 14 for bug 1009816

Hmm, I was confused - when I said earlier:

> A proper "event timestamp" is passed over the remote protocol, but is thrown away because we also have a > "desktop startup ID". The "desktop startup ID" is useful when presenting a new window and includes the
> timestamp information, but isn't something we can use when we're raising an existing window.

I was assuming that the timestamp in:

void
nsGTKRemoteService::SetDesktopStartupIDOrTimestamp(const nsACString& aDesktopStartupID,
                                                   PRUint32 aTimestamp)

was the timestamp from the startup notification protocol, but as you point out, it's not that but rather the event timestamp for the PropertyNotify - so yes, it's not quite proper, and in very rare cases you could get unwanted focus stealing.

The timestamp from the startup notification protocol actually can be parsed out of the ID - SetUserTimeAndStartupIDForActivatedWindow() in the GTK+ nsWindow.cpp doe this using libsn, but it also can be done directly from the string value. (See http://standards.freedesktop.org/startup-notification-spec/startup-notification-latest.txt for how the timestamp is embedded in the launch ID.)

So before calling 'timestamp = GTKToolkit->GetFocusTimestamp();' it would be better to try and parse the timestamp out of the launch ID.

NOTE: That's independent from this bug report - the behavior reported here is as expected unless the user has gone off and interacted further with the originating window before the window is raised.

It's certainly possible to like the old behavior, but it's hard to justify it as a correct - why should Firefox come to the front when it isn't already running, but stay in the background if it was already running? A program like a terminal could offer an "open in the background" option for links which always passed a 0 timestamp to the startup notification spec so Firefox never took focus even if it was already running.