917294 - Focus manager on Windows gets confused when closing a window with an open panel (popup)

Status: RESOLVED INCOMPLETE

(Core :: XUL, defect)

Description

[:Gijs (he/him)]

See bug 916954 and its fix. I'll try and get a more reduced testcase when I'm back home at my Windows machine.

Essentially, STR go something like:

1. Open a second window
2. Open the Australis menupanel (or a similar popup/panel (level=top, without noautofocus or noautohide)) in the second window in a manner that has it taking focus
3. Close the second window

Now I would expect the focus manager's activeWindow property to refer to the first window (which visibly and logically has focus). Unfortunately, it is null. Switching applications fixes this. This is reproducible in all Windows versions we run tests on (XP, Win7, Win8) but doesn't seem to be a problem on Mac or Linux.

(I suppose this could well be a Widget:Win32 bug or something even more exotic, but it seems this might be the best place for XUL focus issues to start out in)

Comment 1

[Neil Deakin]

Gijs, Did you get a chance to make a testcase here? If not, a focus log (set NSPR_LOG_MODULES=Focus:5) may be useful.

Comment 2

[:Gijs (he/him)]

(In reply to Neil Deakin from comment #1)
> Gijs, Did you get a chance to make a testcase here? If not, a focus log (set
> NSPR_LOG_MODULES=Focus:5) may be useful.

I've tried but it's not as simple as I thought initially, so instead of writing the test from scratch (which is what I tried to do last week and got stuck on), I'm planning on going back from the broken testcase I had before and trying to strip that down to the essentials. I can also try and do a focus log against the non-reduced testcase if you think that'd help...

Comment 3

[Neil Deakin]

Anything here would be helpful. It's likely a Windows widget code issue though. There have been other bugs where windows sends messages in a different order than expected. You could also try a build with windows message logging enabled (uncomment the EVENT_DEBUG_OUTPUT line in nsWindowDbg.h and rebuild) and use NSPR_LOG_MODULES=Focus:5,nsWindow:5

Comment 4

[doug2]

In my experience, it seems to "appear" after running TB for a long time or possibly after something else triggers it.  If so, experience would point to dirty or uninitialized memory?  A reboot seems to clean it up.  Shutting down just TB and restarting did not "seem" to resolve the problem.  I'll pay more attention next time.

Comment 5

[doug2]

Shutting down and restarting TB does not correct the problem.  It takes a reboot.  
Separately, my "work offline" flag keeps getting set to true - which may be totally unrelated, but a coincidence.

Comment 6

[:Gijs (he/him)]

Despite trying, I can't seem to reproduce the failure conditions, so I'm marking this as incomplete.