Trunk-only, Mac-only. Regressed between 20061102-04 and 20061103-04. Haven't been able to reproduce in Seamonkey builds, either. When loading certain pages (e.g. Google search), if you quickly switch focus to a different window before the resulting page has started loading, then all form text fields on the resulting page, and text-field browser widgets such as the location, search and find bars, stop accepting input. If you hit the delete key, then it registers not as a text delete, but instead jumps back a page in browser history, suggesting that the toolbar has stolen focus. But if the "other window" that was given focus during loading is also a browser window, then if you click on a bookmark in the "broken" window, then the page loads in that other window instead, suggesting that it has stolen focus. I don't know if there's a simpler way of reproducing this, but this at least works: 1. Open two browser windows 2. Size them small, so you can access both at the same time 3. In window 1, navigate to the Google search page and type something in the search field at the top, but don't hit return just yet 4. Hover the mouse over window 2, but don't focus on it just yet 5. Hit return (so the search begins in window 1), but also immediately click and set the focus somewhere on window 2. You can also hit the search button in window 1, but you have to be fast to change windows... you have to have the focus set to window 2 before the new page starts to draw in window 1 6. After the search page has finished loading, click on window 1. Text fields should now be mostly unresponsive. Hitting the delete key makes the browser go back to a previous page. Clicking on a bookmark in window 1 makes the page load in window 2. 7. Hide and bring back window. Everything should now work again. If you want to repeat this, I've found that sometimes you have to alter the text in the Google search field before it'll work again. Sometimes not. See also Camino bug 352582. But this bug differs in that: 1. The "Full Keyboard Access" pref is irrelevant to this bug - this bug occurs no matter what the pref is set to 2. The regression range given in bug 352582 comment 4 is wrong for this bug. However later reporters have suggested a range that matches this bug, so there may be two bugs involved on Camino? Also note bug 365233 for Firefox 2. The current bug differs in that I can't reproduce the symptoms on Firefox 2 at all, using the steps above. That bug is possibly due to Flash (= bug 355071). From Bonsai, I'm not sure what check-in may have cause this.

Also of note: if I use my default target for my home builds (powerpc-apple-darwin8.9.0) the bug doesn't occur. But if I set --target=powerpc-apple-darwin8.8.4 (the setting for official tinderbox builds) it does. Took me a while to work out why home builds weren't showing the bug.

I encountered the same behaviour (browser window not accepting any focus, neither in location bar nor in input fields) using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a6pre) Gecko/2007060804 Minefield/3.0a6pre Solution as mentioned above: Hide and unhide the window...

Also seeing this - an alternative to hiding and unhiding the window is to focus on a textfield in another app entirely (e.g. the search box in iTunes) then click back to Firefox.

Actually, is this a dupe of bug #354768? The info in that bug is considerably more muddled though...

This seems to have been silently fixed between the 20070611 and 20070612 builds. After all these months, it figures that it would go away a few days after I report it :) In the latter build, libxul is enabled by default (--enable-static and --disable-shared build options were removed... bug 345517). I haven't tested yet, but it could be that change that caused the problem to vanish. If so, I wonder if we can really consider it "fixed" or just hidden? I'll leave the bug open pending further info or advice.

(In reply to comment #4) > Actually, is this a dupe of bug #354768? The info in that bug is considerably > more muddled though... Yeah, that bug has an earlier regression range, and has symptoms that don't all apply here (invisible caret but can still type, for example).

This is driving me crazy in my --disable-libxul builds. It needs to be fixed, there's no reason a libxul build should be required for focus to work.

I should mention that this is 100% reproducible for me with the following steps: -- start Firefox (opens the Google start page) -- enter a bugzilla bug URI, press return -- quickly hit Command-N to open a new window -- wait for the bugzilla window to finish loading -- click in it to bring it to the front -> get the good old ###!!! ASSERTION: win is null. this happens [often on xlib builds]. see bug #79213: 'Error', file /Users/roc/mozilla-checkin/mozilla/content/events/src/nsEventStateManager.cpp, line 988 -- click in a textbox -> no caret, typing does nothing

In my home builds, I found that the regression time was actually 20060928 between 09:00 and 11:00, i.e. exactly when Cocoa was switched on. I'm not sure why the official builds have a different regression time (20061103). Perhaps something subtle changed in the build conditions at that point? To me about:buildconfig for that date looks the same as the day before. One other thing of note: aside from the build conditions I mentioned in comment 1, I only seem to be able to reproduce this (at least at the earlier dates) when I'm using gcc 3.3, not 4.0.

A similar, but not identical focus / text field breakage bug has begun in the official trunk nightlies as of 20070622. See bug 354768 comment 68 for details.

Is anyone seeing this any more? I haven't been bitten by it in ages.

As per comment 11 issue seems resolved. Closing this bug as Resolved-WFM. Feel free to reopen if you encounter this issue again.