339482 - Window loses focus, no keyboard input accepted

Status: RESOLVED FIXED

(Core Graveyard :: Widget: Mac, defect)

Description

[philippe (part-time)]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.9a1) Gecko/20060527 Camino/1.2+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060527 Minefield/3.0a1 ID:2006052722

Recent trunk builds lose focus on the window and  the browser does not accept keyboard input/keyboard shortcuts anymore.  The menus remain functional most of the time.

This happens always if I move another window (from another app) in front of Firefox.
Clicking on the top of the window (titlebar), sometimes bring it back to life.

This started after the 20060523 build (which works correctly). 

Bug 339389 describes something similar in BonEcho build

Reproducible: Always

Steps to Reproduce:
1. launch browser
2. move another app in front, and hide it
3. focus gone, window sometimes appear greyed out

Actual Results:  
keyboard shorcuts fail to react, no reaction to inputting text in textfieds,...

Comment 1

[José Jeria]

> Recent trunk builds lose focus on the window and  the browser does not accept
> keyboard input/keyboard shortcuts anymore.  The menus remain functional most of
> the time.

Any specific date when this started to happen? See bug 269207

Comment 2

[philippe (part-time)]

(In reply to comment #1)
> > Recent trunk builds lose focus on the window and  the browser does not accept
> > keyboard input/keyboard shortcuts anymore.  The menus remain functional most of
> > the time.
> 
> Any specific date when this started to happen? See bug 269207
> 
Hmm, the symptomps are similar as bug 269207, but I have never noticed them until very recently. As said in comment #0, trunk build 20060523 is the last build that worked well for me. Things have gone downhill since then. At first I suspected an extension (I installed Firebug 0.4 recently), but I have the same problems with a new profile and no extensions at all.

Comment 3

[José Jeria]

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

Comment 4

[José Jeria]

Confirming regresion based on dupe

Comment 5

[Joël Kuiper]

Also the windows does not get focus when clicking inside content sometimes. Looks related to the problem. My gut feeling says it is a regression from the landing of bug 54488 , which would result in a regression date of 20060526. But I can't make it solid. 

Comment 6

[Mark Mentovai]

Bug 106695?

OS version you experience this on?

Comment 7

[Mark Mentovai]

Bug 337334?  I highly doubt it's 54488.  Can we get a real window here?  Comment 0 says "This started after the 20060523 build (which works correctly)".  Does this mean that the bug does not occur in 052305 and does occur in 052405?

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006-05-23-05-trunk/
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006-05-24-05-trunk/

Comment 8

[Joël Kuiper]

I've ran the builds below for a couple of minutes, and came to the following conclusion:
2006052305 - wfm
(http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006-05-23-05-trunk/)
2006052405 - wfm 
(http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006-05-24-05-trunk/)
2006052506 - wfm
(http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006-05-25-06-trunk/)
2006052606 - broken
(http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006-05-26-05-trunk/)

I must admit however that I did not test them thouroghly only for about 5 minutes each. Although a couple of minutes is enough to experience the bug in the 2006-05-26-05 build.
By the assumption my testing was correct the following checkins could've caused it:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-25&maxdate=2006-05-26&cvsroot=%2Fcvsroot

At first glance I only see bug 54488 to be possibly related

Comment 9

[Mark Mentovai]

OK.  And your OS version (comment 6)?

Comment 10

[Joël Kuiper]

currently running Mac OS X 10.4.6 on a 1,25Ghz PowerBook G4 

Comment 11

[Mark Mentovai]

I'm unable to reproduce the bug on 10.4.6.  I tried the steps in comment 0 repeatedly to no avail.  I tried using several keyboard layouts and input methods, including US, US Extended (Unicode), and Hiragana (Kotoeri).  I gave the new code from bug 54488 a real good workout.

I do see kEventWindowActivated and kEventWindowDeactivated events being processed in duplicate, which I wasn't expecting and isn't really right.  While this affects TSM activation, it shouldn't really harm it, and was happening before bug 54488 anyway.  I wish I could reproduce it here to know for sure, though.  Are there more specific steps I can apply?  Is there a specific keyboard layout or input method to try?  Are you equipped to test source patches?

Comment 12

[Uri Bernstein]

I am able to reproduce using the steps in comment 0 with
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060525 Minefield/3.0a1 ID:2006052506
(contrary to comment 8).

It seems like after restarting the browser I can't reproduce this for a while - but as soon as I can do it once, I can do it consistently.
For me, clicking the title bar always restores the situation to normal.

Comment 13

[Uri Bernstein]

I found that what triggers this for me is opening a secondary window, such as the download manager. Here are my steps to reproduce:
1. Launch Firefox
2. Press Cmd-J to show Downloads Manager
3. Click back on the main Firefox window to focus it
4. Switch to another app
5. Use Cmd-H to hide it
6. Click back on the main Firefox window
At this point the Firefox window is not responsive to clicks and keystrokes.

From now on, even after closing the downloads manager, repeating steps 4-6 produces the problem.

The regression range I see (with these steps) is 2006-05-24 (WFM) to 2006-05-25 (broken).

Comment 14

[Mark Mentovai]

Uri, what you're talking about sounds like a case of bug 337334, appearing in 052506 after bug 106695.  I can reproduce it using your steps in the 052506 build as you say, but it's fixed in 052605 after the checkin of bug 337334.  Because Joël's regression first appeared in the 052606 build, it's probably a different bug than what you're seeing.

Comment 15

[Uri Bernstein]

Yes, you're probably correct - I can't reproduce this with my steps on the latest nightly.
Sorry for not checking earlier - the problem description seemed very similar to what I was seeing, so I assumed it was the same issue.

Comment 16

[philippe (part-time)]

I could repro again with the following build
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060527 Minefield/3.0a1 ID:2006052722
running on 10.4.6.
and these steps:

1. let Firefox run for a while (load a few tabs, hide app or command tab to another app)
2. bring back Fx (command tab)
3. open Preference Window
4. --> can't swich panes in the Pref Window
5. Close Pref. Window - command W - surprised this worked.
6. main Window seemingly has focus, but keyboard shortcuts not working. Mouse actions are still working though.

At which point, command tab away and back and functionality is restored - for a while.
After doing this 3 times, and while typing this message using camino, I can't even close/quit Fx anymore. One more cycle of command-tab and some functionality is back. e.g. I could not open the DomI from the keyboard.

I'll try a newer build next.

Comment 17

[Phil Ringnalda (:philor)]

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

Comment 18

[Wayne Woods]

The symptoms of this bug seem to be progressive. Certain signs become apparent early on, and if they're ignored, then the problem becomes worse until the browser all but locks up entirely, and refuses to quit. The various symptoms I've observed (but not always at the same time) are:
- Browser refuses to hide with cmd-h
- A lot (or all) keyboard shortcuts fail
- When browser is backgrounded and then foregrounded by clicking on the window, the window moves forward, and the correct menus appear, but none of them are responsive until you click on the title bar.
- Can no longer switch between tabs
- All of the menu items fail, although strangely it's often still possible to minimize the window by double-clicking on the title bar
- Text can no longer be entered into text boxes, including the search and location bars

I've listed the more serious items last, and these seem to often be the last to appear.

With the new error console that's been added to the Tools menu, I do notice that the following errors appear on startup:
Error: Warning: unrecognized command line flag -psn_0_145096705
Source File: file:///Applications/Minefield.app/Contents/MacOS/components/nsBrowserContentHandler.js
Line: 514
Error: this.getTabBrowser() has no properties
Source File: file:///Applications/Minefield.app/Contents/MacOS/components/nsSafebrowsingApplication.js
Line: 516

The "this.getTabBrowser() has no properties" error then continues to be logged on seemingly random occasions. However, not always right before a browser incident.

Comment 19

[Wayne Woods]

I also have an easy way to reproduce the bug now, though it's not something I normally do before the bug appears, so there are obviously many different ways. At least it's a start:
1. Start the browser with a fresh window
2. Open Preferences
3. Switch to one of the preference panes that have internal tabs, which means either the Security or the Advanced tab
4. Try to hide the browser. It should fail, even if you close the Preferences window.
5. The browser may let you quit, but if you continue to play, quitting should become difficult soon after.

From testing, I can confirm this began with the 20060526 trunk nightly. I can also reproduce it in the latest SeaMonkey trunk if I click on certain (but not just any) preferences as well, but I'm not sure exactly which yet. I'm also not sure when it began in SeaMonkey.

Comment 20

[Wayne Woods]

(In reply to comment #19)
> 3. Switch to one of the preference panes that have internal tabs, which means
> either the Security or the Advanced tab

Duh, sorry, I meant the Privacy preferences, not "Security".

Comment 21

[Joël Kuiper]

(In reply to comment #18)
> The symptoms of this bug seem to be progressive. Certain signs become apparent
> early on, and if they're ignored, then the problem becomes worse until the
> browser all but locks up entirely, and refuses to quit. The various symptoms
> I've observed (but not always at the same time) are:
> - Browser refuses to hide with cmd-h
> - A lot (or all) keyboard shortcuts fail
> - When browser is backgrounded and then foregrounded by clicking on the window,
> the window moves forward, and the correct menus appear, but none of them are
> responsive until you click on the title bar.
> - Can no longer switch between tabs
> - All of the menu items fail, although strangely it's often still possible to
> minimize the window by double-clicking on the title bar
> - Text can no longer be entered into text boxes, including the search and
> location bars
> 
> I've listed the more serious items last, and these seem to often be the last to
> appear.
> 
I second that. Howerver I also experience that clicking in the content somtimes does not focus the window (scrollbar remains grayed out). And that from time to time clicking links and other interactive tasks with the webpage fail to work. It seems that all these things are focus related. Are we still asuming that the regression date is somewhere between the 0525 and 0526 build?

Comment 22

[philippe (part-time)]

I happen to have a Tinderbox build: 2006052523 that does not shows the symptoms to the extend I see in more recent builds. It is affected by bug 337334 I think, and only rarely shows problems described here (I kept it running for over two hours). For some reason, the main problem I had with it was handling of form controls. Possibly the first symptoms of this bug ?

Wayne (comment #18), the first error you list , I have seen that one for some time now. Iirc, the issue was raised in the forums, and the verdict was not to worry.

Comment 23

[Uri Bernstein]

TB 19237490 and TB 19257606 are crashes I got when trying to quit after unresponsiveness began. Both are with 2006052804.

Comment 24

[Mark Mentovai]

It feels like this might be a regression from bug 336696.

Comment 25

[Mark Mentovai]

Nope - bug still present with local backout of 336696.  Using the steps in comment 19 (thanks for reducing that, Wayne), I can confirm that this was caused by bug 54488 (good call, Joël).  That makes this mine.

Comment 26

[Wayne Woods]

Strangely, I've never been able to reproduce this on trunk builds I've compiled at home, even though my cvs was kept current. At home, however, I compile with gcc 3.3 and MacOSX10.4u.sdk. I wonder if that's the reason, or if there's something else going on. Just thought it was worth mentioning.

Comment 27

[Mark Mentovai]

Attachment: Fix

I made a careless error in bug 54488.  I introduced a new member variable, nsMacControl::mWindowEventHandler, but forgot to initialize it in the constructor.  The way that nsMacControl is written, the first thing that happens when a control is created is that any existing control is removed.  (The only controls that go through this path now are native scrollbars, but windows always get scrollbars even if they're never displayed.)  The removal code, ClearControl, removes any existing event handlers.  Because mWindowEventHandler would be set to random stack garbage, we'd ask the system to remove an event handler we had no business removing (and that may not even have been an event handler).  What happened next depended on what random garbage we asked the system to remove, and could range from nothing (harmless, no effect) to a crash, and everything in between, including losing the ability to process some or all events.

Random stack garbage is dependent on all sorts of things including the architecture, compiler, compiler settings, and more, so Wayne, it's not surprising that the steps to reproduce would show a bug in some builds but not in the ones you made yourself.  (But there would almost definitely be some other way to get your own build to start doing bad things - it's all dependent on getting the right [or wrong] random stack garbage in the right [or wrong] place at the right [or wrong] time.)

This patch fixes the problem and also moves almost all of the constructor's work out of code and in to initializers.

Comment 28

[Mark Mentovai]

Checked in on trunk.

Comment 29

[Mark Mentovai]

Comment on attachment 223731 [details] [diff] [review]
Fix

Will consolidate with 54488 checkin on 1.8 branch once it's proven.

Comment 30

[Mark Mentovai]

Comment on attachment 223731 [details] [diff] [review]
Fix

Checked in on MOZILLA_1_8_BRANCH (consolidated patch including the branch
version of this patch, bug 54488, and bug 339370 on bug 54488).

Comment 31

[Uri Bernstein]

I'm still occasionally experiencing loss of keyboard input on trunk builds. When it happens, there's no easy way to fix it, and I usually end up restarting the browser.

I don't have steps to reproduce (although I suspect it involves switching between applications when there is more than one Firefox window open). If I manage to find steps, I'll open a new bug.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060617 Minefield/3.0a1 ID:2006061705

Comment 32

[Wayne Woods]

I've experienced keyboard input loss very occasionally in the latest nightlies too. For me, it's been mainly when I type something in the search field and hit return (nothing happens). If you manage to find a reproducible situation and file a bug, could you please post a link here? :) Cheers.