Closed Bug 534412 Opened 10 years ago Closed 7 years ago

nsIXTFElement::onDestroyed triggers JS_ASSERT failures for scripted elements

Categories

(Core Graveyard :: XTF, defect)

x86
Windows 7
defect
Not set

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: WeirdAl, Assigned: alex)

Details

Attachments

(2 files)

Attached file stack trace
JS_ASSERT(!cx->runtime->gcRunning);

I think onDestroyed should be marked [noscript].  From code inspection, I see onDestroyed only gets called when all references to the XTFElementWrapper are gone - and JS code shouldn't be executing anything at that point.
I keep hitting this, and it keeps killing me.  This time I hit it calling:
GetXTFElement()->WillChangeParent(nsnull);

The JS function says:

  willChangeParent: function(parent) {
    var node = this._elementWrapper.elementNode;

    var doc = this._elementWrapper.elementNode.ownerDocument;
    doc.QueryInterface(C_i.nsIDOMNSDocument);
    if ((doc.readyState == "complete") && !parent)
    {
      // We're being removed from an active document.  Notify DOM callbacks.
      for (var i = 0; i < this.__DOMEnabledCallbacks__.length; i++)
      {
        var callback = this.__DOMEnabledCallbacks__[i];
        callback.call(this, false);
      }
    }
  },

XPConnect peers:  is this XTF misbehaving, XPConnect, JavaScript Engine, or something stupid I'm doing?  If needed, I can submit a testcase, but reducing it will take some time.
Comments 1 and 2 are a separate bug - filed as bug 543304.  (It just took me three weeks to realize it.)
so, roughly, xpconnect is one of very few co-conspirators wrt jsgc, as such, it shouldn't allow js methods to be called when it knows gc is running. but that would solve your crash w/o resulting in happy code.
XTF is dead.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.