630386 - (NS_ERROR_NOT_AVAILABLE) [nsIDOMJSWindow.setTimeout]

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[John J. Barton]

I get the subject error in FF3.6, not in FF4.0.

This is FYI, we'll just not use the feature in FF3.6.

When I run the following code in evalInSandbox:

    FBTrace.sysout("In delayAdd window.setTimeout is "+window.setTimeout, window);
    window.dump("-> "+window.location+" <-\n");
    window.setTimeout(function delay() {
        FBTrace.sysout("delayAdd = "+a+b);
    });

I get the FBTrace output that window.setTimeout is native, and that the window.location is browser.xul. But the next statement fails with
(NS_ERROR_NOT_AVAILABLE) [nsIDOMJSWindow.setTimeout].

Thus global sandbox object has 'window' and 'FBTrace', but something breaks when trying to call setTimeout.
---
Boris replies to Josh:
On 1/31/11 11:50 AM, Josh Matthews wrote:
> I see
>
>  > if (IsOuterWindow()) {
>  > nsGlobalWindow* callerInner = CallerInnerWindow();
>  > NS_ENSURE_TRUE(callerInner, NS_ERROR_NOT_AVAILABLE);
>
> in nsGlobalWindow::SetTimeoutOrInterval.

Oh, indeed.  And that walks up the scope chain and tries to get the window off the scope chain root (which for a normal web page is the inner window, but in this case is a Sandbox object).

Funtimes.

Should this be using nsJSUtils::GetStaticScriptGlobal instead of trying to get the window directly?  We hacked that so that as long as you initialize the sandbox with a Window it'll do the right thing...

Alternately, failure to get a callerInner should perhaps mean we just don't do the "redirect to that inner" thing and press on.

Testcase:

svn co https://fbug.googlecode.com/svn/tests/mozilla/setTimeout
This is an extension that works in both FF 3.6 (conventional) and 4.0 (bootstrap.js).

Comment 1

[Justin Lebar (not reading bugmail)]

> I get the subject error in FF3.6, not in FF4.0.
> This is FYI, we'll just not use the feature in FF3.6.

So there's no bug in FF4.0?  If so, this is worksforme.  If I misunderstand, please re-open!

Comment 2

[John J. Barton]

Its up to Boris to make that call. Just because it works in 4.0 does not make it works for everyone, and more over we don't no why it works in 4.0 because we don't know why it does not work in 3.6.

Comment 3

[Justin Lebar (not reading bugmail)]

> Just because it works in 4.0 does not make it works for everyone

It's WORKSFORME, not WORKSFOREVERYONE.  :)

In all seriousness, this isn't a security issue, so we're not going to take a fix on 3.6, right?

> more over we don't no why it works in 4.0 because we 
> don't know why it does not work in 3.6.

Fair enough, but I'm not sure that's a bug.

Comment 4

[Boris Zbarsky [:bzbarsky]]

This got fixed as a side-effect of fixing bug 616397, I assume.

Comment 5

[Boris Zbarsky [:bzbarsky]]

And note that per HTML5+WebIDL spec this probably shouldn't work at all; I suspect that once we implement WebIDL-compliant bindings this will break....

Comment 6

[Boris Zbarsky [:bzbarsky]]

Though maybe we'll special-case Window to deal.