911554 - JavaScript strict warning: chrome://global/content/bindings/browser.xml, line 227: reference to undefined property this.boxObject.QueryInterface(...).docShell

Status: NEW

(Thunderbird :: General, defect)

Description

[ISHIKAWA, Chiaki]

Everytime I start DEBUG BUILD of thunderbird (under 32bits and locally build 64bits)
I get the warning:

JavaScript strict warning: chrome://global/content/bindings/browser.xml, line 227: reference to undefined property this.boxObject.QueryInterface(...).docShell

Coded in question is this:

      <property name="docShell"
===>            onget="return this._docShell || (this._docShell = this.boxObject.QueryInterface(Components.interfaces.nsIContainerBoxObject).docShell);"
                readonly="true"/>


This warning is followed by a series of warnings that get printed afterward:
++DOMWINDOW == 15 (0x18b119b8) [serial = 16] [outer = 0x1c6dbf78]
GetProp:98: nbytes=128
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv) && subjPrincipal) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/docshell/base/nsDocShell.cpp, line 8413
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv) && subjPrincipal) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/docshell/base/nsDocShell.cpp, line 8413
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv) && subjPrincipal) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/docshell/base/nsDocShell.cpp, line 8413
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv) && subjPrincipal) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/docshell/base/nsDocShell.cpp, line 8413
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv) && subjPrincipal) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/docshell/base/nsDocShell.cpp, line 8413
++DOMWINDOW == 16 (0x25153338) [serial = 17] [outer = 0x2706b238]
WARNING: Subdocument container has no frame: file /REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsDocumentViewer.cpp, line 2339
++DOMWINDOW == 17 (0x1ca17ca8) [serial = 18] [outer = 0x27078b38]
++DOMWINDOW == 18 (0x282d6de8) [serial = 19] [outer = 0x2707c2d8]
WARNING: Subdocument container has no frame: file /REF-COMM-CENTRAL/comm-central/mozilla/layout/base/nsDocumentViewer.cpp, line 2339
++DOMWINDOW == 19 (0x242529c8) [serial = 20] [outer = 0x1c52b5a8]

I am not sure if TB, a mail client, is handling web-related data structure
correctly at the startup.

TIA

Comment 1

[:aceman]

I see this too. I think it only started recently (some weeks ago). Either toolkit has removed some functionality TB needs, or TB needs to be updated to accommodate some change in this toolkit file.

Comment 2

[ISHIKAWA, Chiaki]

(In reply to :aceman from comment #1)
> I see this too. I think it only started recently (some weeks ago). Either
> toolkit has removed some functionality TB needs, or TB needs to be updated
> to accommodate some change in this toolkit file.

It is possible that this problem is easily manifested in the recent builds,
but |make mozmill| test suite run printed this warning 
earlier this year (all the way back to January.)

The reason I posted this bugzilla entry now (September, that is),
is that, over the months, the number of issues easily noticeable
and looking manageable in the session log has decreased 
thanks to you, aceman, and other people.

So now, I finally had the time to pay attention to this
warning/error which seems to be printed near the beginning of a session.

We still have many warnings/errors to take care of, but I think we
have made a certain progress this year. :-)

We now have more difficult errors/warnings left, though :-(

TIA

Comment 3

[ISHIKAWA, Chiaki]

I hasten to add that I am running my local build of TB (comm-central) and
so if you are using a pre-built binary, then it certainly makes sense that
this problem has begun manifesting itself in recent builds (weeks).
comm-central source tree predates the offered binary significantly, I think.

TIA

Comment 4

[:aceman]

I do a debug build TB too from a very often updated tree. The "few weeks" quote is just my feeling. It is also possible the warning is there for a year.

Comment 5

[[e-mail]]

(In reply to ISHIKAWA, Chiaki)
> JavaScript strict warning: chrome://global/content/bindings/browser.xml,
> line 227: reference to undefined property
> this.boxObject.QueryInterface(...).docShell
> 
> Coded in question is this:
> 
>       <property name="docShell"
> ===>            onget="return this._docShell || (this._docShell =
> this.boxObject.QueryInterface(Components.interfaces.nsIContainerBoxObject).
> docShell);"
So, this should never happen, because the QueryInterface guarantees that the return value implements all the properties of the requested interface, which in this case is the readonly attribute docShell.

However, what I have seen happen, is that calling C++ code triggers some other JS code to run, and that JS code throws an exception which is caught by the C++ code, but gets erroneously reported anyway (with incorrect line number and variable names, too!)

Comment 6

[ISHIKAWA, Chiaki]

(In reply to [e-mail] from comment #5)
> (In reply to ISHIKAWA, Chiaki)
> 
> So, this should never happen, because the QueryInterface guarantees that the
> return value implements all the properties of the requested interface, which
> in this case is the readonly attribute docShell.

I thought of breaking down 
return this._docShell || (this._docShell = 
this.boxObject.QueryInterface(Components.interfaces.nsIContainerBoxObject)
to something like

  onget="if (this._docshell)
              return this._docshell;
         if (!this.boxObject)
              dump("boxObject is null"); 
         if (!this.boxObject.QueryInterface(Components.interfaces.nsIContainerBoxObject))
              dump("boxObject.QueryInterface(... ditto ...);
         return this._docShell = this.boxObject.QueryInterface(Components.interfaces.nsIContainerBoxObject);
         "

to see if this.boxObject has a funny value or something, but then this would be in vain, then.
 
> However, what I have seen happen, is that calling C++ code triggers some
> other JS code to run, and that JS code throws an exception which is caught
> by the C++ code, but gets erroneously reported anyway (with incorrect line
> number and variable names, too!)

Wow, tough luck. :-(
Is there any way to improve on this situation? I wonder what causes this incorrect reporting.
It sounds an XPCOM interface library bug to me. (Maybe impossible to fix?)

Well, it sounds then it boils down to "Ignore this bug safely".
Or doesnt it?