This block of SetUserTimeAndStartupIDForActivatedWindow() is a little
confusing. It doesn't set the user time or the startup id for the activated
window. Instead, it sends an "activate me, please" message to the window
manager. I understand it's just a workaround when no startup id is available
(because either firefox wasn't launched with startup-notification or wasn't
built with MOZ_ENABLE_STARTUP_NOTIFICATION), but it'd be nice to have it
documented as such. It'd also be good to verify in testing that this block of
code isn't being executed (i.e. that startup id is non-empty), since it is just
a workaround.
*****************
I find it odd that the supposed 'workaround' part of the code is what's causing
the problem in my testing.
So, going back to the beginning. The original patch (for firefox) has the /bugzilla. mozilla. org/show_ bug.cgi? id=223492# c31):
following comments usptream from Elijah
(https:/
************ ID.IsEmpty( )) { >GetFocusTimest amp(); focus(aWindow- >window, timestamp); >SetFocusTimest amp(0);
>+ if (desktopStartup
>+ PRUint32 timestamp = GTKToolkit-
>+ if (timestamp) {
>+ gdk_window_
>+ GTKToolkit-
>+ }
>+ return;
>+ }
This block of SetUserTimeAndS tartupIDForActi vatedWindow( ) is a little notification or wasn't STARTUP_ NOTIFICATION) , but it'd be nice to have it
confusing. It doesn't set the user time or the startup id for the activated
window. Instead, it sends an "activate me, please" message to the window
manager. I understand it's just a workaround when no startup id is available
(because either firefox wasn't launched with startup-
built with MOZ_ENABLE_
documented as such. It'd also be good to verify in testing that this block of
code isn't being executed (i.e. that startup id is non-empty), since it is just
a workaround.
*****************
I find it odd that the supposed 'workaround' part of the code is what's causing
the problem in my testing.