I thought this would be fixed when mail and news was fixed, but apparently not. When I click the chatzilla button I can move the window to the back. As soon as it connects to the server it pops to the front. It should stay at the back where I told it to go.

It also pops to the front when there is activity in a channel or other window - very annoying.

I don't see this on Linux. I'll try to test it on Windows. You can make it stop taking focus when people message you, by typing: "/eval client.FLASH_WINDOW=false". This setting is persistant.

Had this on linux. Well, hope your tip works: [EVAL-IN]client.FLASH_WINDOW=false [EVAL-OUT]false

This also occurs twice after clicking a chatzilla IRC URL that includes a channel. It will give focus when it connects to the server and when it joins the channel.

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

Just for the sake of completeness: If you choose to auto-open some channels at chatzilla startup, the chatzilla window pops in front for joining each and every of these channels and their servers, which makes mozilla practically unusable for some time until all connections are made.

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

Commenting out line 50 in handlers.js in chatzilla.jar (http://lxr.mozilla.org/seamonkey/source/extensions/irc/xul/content/handlers.js#50) prevents this bug from happening. Since that line calls "input.focus()" and the input element is a textbox I think this is caused by bug 124750. However, I don't know yet about the side-effects of removing this line. One of them is that after editing the channel topic the input line is not automatically focused again (which is surely less annoying). I'll try to find a solution without side effects.

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

One quick-and-dirty option is to do if (document.commandDispatcher.focusedElement != client.input.mInputField) client.input.focus(); Another possibility is if (Components.classes["@mozilla.org/embedcomp/window-watcher;1"] .getService(Components.interfaces.nsIWindowWatcher) .activeWindow == window) client.input.focus(); else document.commandDispatcher.focusedElement = client.input; }

This patch implements the second proposal from comment #10. -> Patch bei Neil. He told me on IRC that this is good enough as a 'final' patch. It uses the approach from navigator.js, around line 630, to prevent the problem from appearing (see bug 97067): it only sets focus to the input field if the window is already the active one. If it isn't, the focus is only remembered and then restored, when the window becomes active. Requesting review from rginda.

Comment on attachment 113890 [details] [diff] [review] Patch (by Neil) I don't like to break lines in the middle of an object reference. I'll post a patch with more acceptable line breaking.

I'll post a new xpi with this fix to hacksrus.

Great! Well... that patch seems to content some more stuff... but I'm sure only good stuff. :-)

Oops, I forgot that suff was still in there. Thats from bug 191910.

Comment on attachment 114242 [details] [diff] [review] same patch, different line breaks > function focusInput () > { >- client.input.focus(); >+ const WWATCHER_CTRID = "@mozilla.org/embedcomp/window-watcher;1"; >+ const nsIWindowWatcher = Components.interfaces.nsIWindowWatcher; >+ >+ var watcher = >+ Components.classes[WWATCHER_CTRID]..getService(nsIWindowWatcher); >+ if (watcher.activeWindow == window) >+ client.input.focus(); >+ else >+ document.commandDispatcher.focusedElement = client.input; On my Linux, the input field of cz0.8.22 doesn't get focus. I have to click the field before writing a message. Win98 doesn't have any problem.

You can press the Esc key to focus the input line.

I've noticed this problem too. ESC doesn't even focus the field for me at first. I have to click to give the input field focus the first time, but after that it works as expected. I suspect this is a bug in the focus code itself. It would be nice if we could find a workaround though.

checked in