David Flanagan [:djf] Reporter
	Description • 13 years ago

Web console appears to be evaluating js expressions typed at the command line using a different global object than the one associated with the window to which the console is attached.

To demonstrate:

1) Open Web Console

2) Load a document that contains this code in a script:

var a = [1,2,3];
var global = this;

3) In the console, type "a instanceof Array".  It responds false.  (But note that a is defined and appears to be the 

4) In the console, type "global === this".  Again, it responds false.

5) In the console, type "a instanceof global.Array" and you'll get true.

So somehow, web console is copying all user-defined properties from the window object to its own, but is not copying the js built-ins.

This kind of unpredictable execution environment is obviously not okay for a debugger.  

I see this behavior in the 6/19 Aurora build.  It does not happen in FF5RC.

	Panos Astithas (he/him) [:past] (please ni?) Assignee
	Comment 1 • 13 years ago

I can't reproduce this in the latest Nightly from the devtools repo.

	David Flanagan [:djf] Reporter
	Comment 2 • 13 years ago

Its still in the 6/20 6.0a2 Aurora build, though. Is the current branch of the devtools repo targeting Firefox 6?

	Panos Astithas (he/him) [:past] (please ni?) Assignee
	Comment 3 • 13 years ago

The devtools repo is used to test devtools patches before merging to mozilla-central, so it currently targets Firefox 7. This looks like a regression that is already fixed, but I don't know which commit fixed it or broke it in the first place.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 4 • 13 years ago

If this works in 5 and 7 but not 6, we should probably figure that out ASAP so that we can get a patch on Aurora.

	Panos Astithas (he/him) [:past] (please ni?) Assignee
	Comment 5 • 13 years ago

I take my previous comments back. I was testing by typing code in the web console, not loading a web page with the definitions for "a" and "global". When following your instructions I still witness the same behavior as you, but I have confirmed that this happens in 4.0.1, 5, 6.0a2 and Nightly. IIRC FF5RC is the same as 5 final?

So it appears that this is indeed a bug, but not a regression.

	David Dahl :ddahl
	Comment 6 • 13 years ago

From what I remember from the initial console implementations, we saw things like this because the frame the object is created in is not the same frame we are doing the instanceof test in. The execution context inside of the sandbox is not *exactly* the same as the context of the window - almost, but it is still a sandbox, for security reasons. I will CC mrbkap to weigh in on this.

	David Dahl :ddahl
	Comment 7 • 13 years ago

btw, you can use htmlpad.org to make simple pages like the one needed for the STR: http://htmlpad.org/consoletest/

	Panos Astithas (he/him) [:past] (please ni?) Assignee
	Comment 8 • 13 years ago

This behavior seems similar to bug 664689. Unfortunately, I can't use the same workaround here.

	Panos Astithas (he/him) [:past] (please ni?) Assignee
	Comment 9 • 13 years ago

Apparently it was a deliberate decision to not have this === window in the web console, to avoid polluting the page namespace, as can be seen in bug 641629. Boris, do you happen to know if there is a similar reason for the behavior of instanceof? Could this be related to bug 641655?

	Boris Zbarsky [:bzbarsky]
	Comment 10 • 13 years ago

> Boris, do you happen to know if there is a similar reason for the behavior of
> instanceof?

I would assume that instanceof behaves the way it does because the web console global _is_ a global and hence has standard classes directly defined on it.  These shadow the standard classes defined on the window up its proto chain.

I doubt this is related to bug 641655.

Fundamentally, in the above testcase, |a| and |[]| (an array literal) would be arrays that come from different globals.  So you can't have both |a instanceof Array| and |[] instanceof Array| test true there.... unless there are some sort of JS engine changes to help out here.  For example allowing standard class lookups to happen on one object while var definitions happen on another object.  Or custom "standard class" objects on the sandbox that do some sort of magic.  Or something.

Or just give up and allow pollution of the page global if someone declares or sets to a variable in the console...

	Jim Blandy :jimb
	Comment 11 • 13 years ago

(In reply to Boris Zbarsky (:bz) from comment #10)
> Or just give up and allow pollution of the page global if someone declares
> or sets to a variable in the console...

I would say "permit modification of the page global". :)

	Boris Zbarsky [:bzbarsky]
	Comment 12 • 13 years ago

You can modify the page global in the console.  Just set window.foo to get it to show up in the page as a property on the global named "foo".

The point of the current setup is to prevent accidentally adding properties to the page global just because you happened to assign to some variable in the console.

	Kevin Dangoor
	Comment 13 • 13 years ago

(In reply to Boris Zbarsky (:bz) from comment #12)
> You can modify the page global in the console.  Just set window.foo to get
> it to show up in the page as a property on the global named "foo".
> 
> The point of the current setup is to prevent accidentally adding properties
> to the page global just because you happened to assign to some variable in
> the console.

This bug and bug 690529 are basically for the same thing, and I think they both make the point that the current behavior can be difficult to understand (especially for people who aren't putting much thought into what the tool is actually doing) and contrary to what other tools do.

	Boris Zbarsky [:bzbarsky]
	Comment 14 • 13 years ago

OK, that's fair.  If you want to change the design criteria for the tool, that's a separate issue entirely.

	Kevin Dangoor
	Comment 15 • 13 years ago

There's a bit more detailed discussion in bug 690529.