17952 - Can't do window.setTimeout() or window.close() when attempted by way of xpconnect

Status: RESOLVED FIXED

(Core :: XPConnect, defect, P1)

Description

[Bill Law]

The code in mozilla/xpfe/components/xfer/resources/downloadProgress.js
implements an xpcom interface (nsIObserver) in JavaScript and that
implementation is called from C++ code (namely, ../src/nsStreamXferOp.cpp).

When called to be notified that the download is complete, the dialog attempts to
close itself.

window.setTimeout( "window.close();", 2000 ); causes a JS exception to be thrown
because there's no JSContext on the stack (some security manager code fails).

window.close(); directly just fails.  I think this is because the close gets
scheduled as a "termination function" and it ultimately doesn't get called (or
fails) due to the same root cause.

This is a problem.

Unfortunately, the code to reproduce this sits only in my working directory.  If
you need assistance reproducing it, let me know and I'll get you my changes or
create a testcase that can reproduce this.

Comment 1

[Brendan Eich [:brendan]]

We're between worlds (broken JSContext overloading, fixed XPConnect
ThreadJSContextStack usage) and it sucks.  We need to move the DOM state that's
mislocated in JSContext into the window object private, reparameterize as needed
and stuff.  I'll help.

/be

Comment 2

[John Bandhauer]

This depends on (is sort of a duplicate of) bug 17736

Comment 3

[John Bandhauer]

Bill, I believe this should be fixed with my xpconnect refactoring that went in
today. The similar bug 17736 is fixed. I'm reasigning this to you. Could you
please run whatever test you have - if it is not too difficult to set that up -
and either mark it fixed or reassign to me if there is still a problem.

Comment 4

[Bill Law]

I'll check it out (will have to change JS that was modified to bypass the
problem).  The setTimeout() started working a little while back but
unfortunately caused a crash when it did window.close().  window.close() in a
xpconnect invoked JS method was not working and may with this most recent fix.

Comment 5

[don]

M14.

Comment 6

[Brendan Eich [:brendan]]

Is this fixed in M13?  If so, its TM need not be M14.  Just curious,

/be

Comment 7

[Bill Law]

The problem is fixed.  I just verified it on Mac and Linux (each of which had
window closing quirks till recently).

I have not reset the code in downloadProgress.js.  I've got some other bug fixes
in that file and am waiting for a code review to be completed.  I hope to check
that code in later today.

I'm resetting this to M13 so I'll remember to close this one, too, after the
code is checked in.

Comment 8

[Bill Law]

JS code has been reverted to use the technique that was previously causing the
problem.  Everything looks good now.

Comment 9

[R.K.Aa.]

is bug 49138 a dup of this? If so, something has regressed.