Now that chrome is loaded synchronously, there should be no need to delay focus() calls using setTimeout(). Removing them would fix a problem which causes minimized windows to get restored when the user minimizes the window before the setTimeout() call fires. I'll mark some bugs as a duplicate of this.

*** Bug 163372 has been marked as a duplicate of this bug. ***

I believe there should be other bugs caused by this very problem. I just can't find them now.

Ere I'm uncertain -- scratch that, actually I'm just ignorant -- what you're referring to with the synchronously loaded chrome. Actual xul file I/O is of course asynchronous. That's turned into effectively synchronous loading of chrome before the call to open a content window returns, but that's old news. Do you mean fastload? I understand fastload bypasses necko for direct synchronous system I/O but you can't count on that behaviour since sometimes fastload itself is bypassed. As I mentioned in bug 163372 comment 31, long ago setTimeout became a widely used trick to put off execution of code dependent on window construction having finished. The bugs it saved us from included crashes, but other more subtle problems as well. I'd be leery of declaring the conditions that caused us to add these setTimeouts fixed and removing them all. I'm struck by the wording of the subject of this bug, which stands in direct opposition to bug 91788 and spinoff bug 91884, whose title reads "should never call focus() directly in navigator.js (and other places?)". As far as I know the conditions that caused us to use setTimeout around focus for those bugs, still exist.

What I meant was synchronously loading xbl bindings, which we do. Calling focus() via setTimeout() has some bad side effects. As setTimeout() uses idle timers, the user might have done numerous things after the timer was armed and before it fires. A good example is minimizing the window which pops back up when the timer fires. From what I've gathered (I've tried to find all the bugs about this, but there are quite a few) the main problem previously was that xbl bindings hadn't necessarily loaded before the code that set the focus was executed. I know this is contrary to bug 91884, but I think using setTimeout() is a hack with its own problems and we should try to do without it. I'm aware of the risk and therefore I'd like to try to put up a patch and get some people test drive it first on different platforms to see if problems crop up.

This is a test patch for trying to live without setTimeout() in a few places. This needs some serious testing on different platforms. I've tested Windows XP only. Especially Mac testing would be interesting, as originally there were some problems with dialogs showing empty. Anyone willing to give it a shot?

Comment on attachment 125012 [details] [diff] [review] Test patch >+ { >+ } Bah. >- setTimeout(WindowFocusTimerCallback, 0, gURLBar); >+ FocusWindow(gURLBar); > else >- setTimeout(WindowFocusTimerCallback, 0, _content); >+ FocusWindow(_content); Isn't WindowFocusTimerCallback a hack anyway, can't we be sure that we can simply call focus() now?

I believe the rest of it is to avoid focus grabbing if the user switches to another app before the Mozilla window manages to come up.

Well, I tried changing it to focus and I noticed no difference - am I missing something? On Windows 98, a) ^N, switch to another Moz window, new browser always activates b) ^N, switch to another app, new browser never activates

What do a) and b) represent? Maybe I mistook the idea of the code.

[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4) Gecko/20030624] Just got one of thoses bug 163372 like behaviour: minimizing another app., Mozilla restored.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624] Just got one of thoses bug 163372 like behaviour: auto-restored soon after minimizing, while a page was loading. *** Adding "(minimize -> auto-restore behaviour)" to the summary.

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420