56063 - document.commandDispatcher.focusedWindow is undefined, loading <frame>s

Status: VERIFIED WORKSFORME

(Core :: XUL, defect, P3)

Description

[John Morrison]

http://home.wtal.de/software-solutions/jindent/frameset.html

Overview Description:
  On a frameset page, on Windows, the following error message
  is hit when clicking on a link to load a new URL into the
  frame:

    JavaScript error:
      chrome://navigator/content/navigator.js line 118:
      focusedWindow.location has no properties

Steps to Reproduce:
1) Go to the test URL
2) Click in a link on the right hand frame
3) Look in the console

Build Date & Platform Bug Found:
  2000101008 mozilla trunk build (as well as a branch build) win2k

  DOES NOT OCCUR:  Linux
  NO HAVE CONSOLE: Mac

Additional Information:

This means that this code is failing (from navigator.js):

function contentAreaFrameFocus()
{
  var saveFrameItem = document.getElementById("savepage");
  var focusedWindow = document.commandDispatcher.focusedWindow;
  if (isDocumentFrame(focusedWindow)) {
    gFocusedURL = focusedWindow.location.href;
    saveFrameItem.removeAttribute("hidden");
  }
}

In particular,  document.commandDispatcher.focusedWindow is undefined.

However, I put in some dump statements, and this function is called more
than once during the page load, and eventually the right answer is
returned. So, this may be harmless (but could be put in a try clause
someday, so it doesn't abort pointlessly).

hyatt, ben, saari: any worries about the apparent momentary loss of focus?

Comment 1

[John Morrison]

example URL

Comment 2

[Peter "jag" Annema]

  var focusedWindow = document.commandDispatcher.focusedWindow;
  if (isDocumentFrame(focusedWindow)) {

which calls this:

function isDocumentFrame(aFocusedWindow)
{
  var contentFrames = _content.frames;
  if (contentFrames.length) {
    for (var i = 0; i < contentFrames.length; ++i) {
      if (aFocusedWindow == contentFrames[i])
        return true;
    }
  }
  return false;
}

So, what's interesting is that if focusedWindow (aFocusedWindow) really is
undefined, then it's matching against contentFrames[i], which strikes me as
rather odd. Also, I asked Fabian to test this for me with some strategically
placed dumps, and he always saw [object window] dumped. I'll verify this in a
bit.

Comment 3

[Peter "jag" Annema]

Here is the output of:

function contentAreaFrameFocus()
{
  var focusedWindow = document.commandDispatcher.focusedWindow;
  dump("--- focused: "+focusedWindow+"...\n");
  if (isDocumentFrame(focusedWindow)) {
    try {
      gFocusedURL = focusedWindow.location.href;
    } catch (e) {
      dump(e);
      for (var el in focusedWindow)
        dump(el+", ");
      dump("\n");
    }
    var saveFrameItem = document.getElementById("savepage");
    saveFrameItem.removeAttribute("hidden");
  }
}

----------

--- focused: [object Window]...
TypeError: focusedWindow.location has no properties
focusedWindow properties: top, _content, sidebar, prompter, menubar, toolbar, 
locationbar, personalbar, controllers
--- focused: [object Window]...
TypeError: focusedWindow.location has no properties
focusedWindow properties: top, _content, sidebar, prompter, menubar, toolbar, 
locationbar, personalbar, controllers

----------

According to the code, this is one of the frames in _content.frames, so why 
doesn't it have a location property?

Comment 4

[Keyser Sose]

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

Comment 5

[HJ]

Peter, this is about line 91 in navigator.js, right?

You know that we talked about this type of errors weeks ago. I then asked you to
check a site I had problems with. On December 12 I discovered that when you set
cache to 0 in preferences, that in that specific case, I no longer get that
message in the JavaScript console. And the other problems are fixed also. I just
checked this, and it's still working the same in build 2000122920.

You might remember that I use event handlers to trigger keystokes on that site.
Ian asked me for a working testcase, so I took a second look in the source. I
now discovered that this problem is caused by an other bug. Related to event
handling, I filed this one weeks ago.

So for my problems, and that might work for this site the same, when I use
specific event handlers, I see this message in the console. onClick and
onkeyPress are triggering this error. Why? Because onkeyPress is triggered
twice, if you stop this like I did now, the problem is gone!

I have yet to find out if this is the case for the onClick event. I like to hear
from you really soon. Maybe this can be fixed. At least I have a work around at
this time. The fix, thats your job, right?

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 7

[HJ]

Small note, this message only occures when the event document equals the frame
target document. And this is the case for both onmouseclick and onkeypress.

Comment 8

[HJ]

Small note, this message only occures when the event document equals the frame
target document. And this is the case for both onmouseclick and onkeypress.

Comment 9

[HJ]

Changes to the source of navigator.js produce more errors on the console! All
about line 81 now. Now I can't count the number, there are simple to many after
a simple visit to a site, using framesets. Is this a site affect of the latest
"improvements" to that file? The bugs are still the same, in the latest build,
only the number of errors is increasing.

Comment 10

[John Morrison]

I think this bug is worksforme (when the fix is made for bug 65228).

Comment 11

[Fabian Guisset]

worksforme with the fix for bug 65228, no longer seeing the errors (but is
focusedWindow defined now?). John can you please verify?

Comment 12

[John Morrison]

Yeah, this is all better now ...

Comment 13

[John Morrison]

le verified