Some addons developers use such code in overlays to access to the focused window : window.addEventListener("load", foobar, true); function foobar() { // something with document.commandDispatcher.focusedWindow } With Firefox 3.0, it works. In the current trunk, such code doesn't work (focusedWindow is null) just after the launch of Firefox. The code broking it is the patch from bug 365467.

Um... the window isn't actually visible yet, so how can it be focused?

(In reply to comment #1) > Um... the window isn't actually visible yet, so how can it be focused? Neil, of course, you're absolutely right. The problem here is that it's still a regression from previous versions of Firefox. If we believe the current behavior is correct then we shouldn't revert. We'll just have to evangelize hard to get the word out to any add-on developers using the code pattern Paul mentions in comment 0. I think Paul found that the exact same code works in subsequent window opens, just not the first. If that is true, then there could still be something broken. Unless document.commandDispatcher.focusedWindow is pointing to the previously opened (and focused) window while the second (and subsequent) window is opening.

Well, I admit I don't see why anyone was using the old pattern. The problem with that code snippet is that the focusedWindow was whichever frame loaded first. Anyone using that in a load event should really find the window they want more reliably. I guess it might be possible to make it default to the topmost chrome window but I'm not sure how that would work in an embedding context.

What kind of code should they use ? I would say : Application.activeWindow;

Legacy extensions are no longer valid in Firefox 57, closing.