848116 - nsIWindowMediator is not returning the correct active window, also window.focus() DNW

Status: NEW

(Core :: XUL, defect)

Description

[Erik Vold [:erikvold] (please needinfo? me)]

Attachment: example add-on of the issue

I've attached a test add-on, that expects one non-private window to be opened when it is installed/enabled.

The add-on basically does this:

1. Opens a private window
2. Waits for the private window to focus and checks that it is the active window from nsIWindowMediator
3. Steps 1&2 for non private window
4. Step 1&2 again
5. Step 3 again

At this point the focused window should be the non-private window, but it is actually the private window.  Also the check in step 4 that the active window from nsIWindowMediator is the private window will always fails.

Comment 1

[Erik Vold [:erikvold] (please needinfo? me)]

Hmm sorry this isn't specific to private windows, if I remove the private flag in the test add-on then I still have the same issue.

Comment 2

[Erik Vold [:erikvold] (please needinfo? me)]

Attachment: jetpack main.js file for easy reading

Comment 3

[Erik Vold [:erikvold] (please needinfo? me)]

you can probably use the main.js file on Builder or with ScratchKit for testing too.

Comment 4

[Erik Vold [:erikvold] (please needinfo? me)]

I had to work around this issue in bug 846856 and bug 846854, so there are two other examples too.

Comment 5

[Alexandre Poirot [:ochameau]]

Sounds more like a Core:XUL bug.
I'd tend to think that we are hitting a race condition when focus event is dispatched.
We are trying to change the focused window during the same event loop iteration...

The important fact is that, it only fails if we try to focus a window while we are in the focus event listener. i.e. if we delay window.focus() with setTimeout 0, it works.

I wouldn't surprised if some state variable introduce this behavior:
  http://mxr.mozilla.org/mozilla-central/source/dom/base/nsFocusManager.cpp