273073 - Venkman doesn't respect JavaScript language in Interactive Session

Status: RESOLVED WORKSFORME

(Other Applications Graveyard :: Venkman JS Debugger, defect)

Description

[Bob Clary [:bc] (inactive)]

If you are debugging a page which contains javascript which has been invoked
using a specific javascript version, code executes in the browser in the correct
javascript version but if you evaluate the code in the interactive session the
code will be executed as if the language version is 1.5.

To see this interactively, turn on strict warnings, open venkman, enable pretty
print, open the online js test suite, pick ecma/String/15.5.4.8-3.js as the
test, set the language version to javascript1.2, and execute. You will see the
following warning:

Warning ``reference to undefined property s.split(" ")[0]'' [xs] in file
``http://bclary.com/2004/10/03/js-tests/ecma/String/15.5.4.8-3.js'', line 143,
character 0.

#0: function (null)() in
<http://bclary-com.bclary.com/2004/10/03/js-tests/ecma/String/15.5.4.8-3.js>
line 143
001: var s = new String(" ");
002: s.split(" ")[0];
0007: s.length
$[0] = [integer] 1
0007: s.split(" ").length
$[1] = [integer] 2
0007: s.split(" ")[0] === ""
$[2] = [boolean] true

I would expect to be able to run interactive commands in the same language
version the script is executing under.

Comment 1

[:Gijs (he/him)]

Right now we're using 1.7 as default, which I think should work in most cases unless "artificially" restricting the language to an earlier version (as in your example). I'm not sure how common that usecase is. From the fix to get 1.7 (see the dep bug), I'm not sure there's a reasonable way to get this general fix. Do you have suggestions?

Comment 2

[Bob Clary [:bc] (inactive)]

When this bug was filed, we changed the behavior of the js engine to match the version. We no longer do that however so in most cases I think the default of 1.7 will work fine. But what about cases where people are setting the version to 1.8 ? They may want to test the newer js features in 1.8 possibly. Either way, this is not a common problem anymore.

Comment 3

[:Gijs (he/him)]

(In reply to comment #2)
> When this bug was filed, we changed the behavior of the js engine to match the
> version. We no longer do that however so in most cases I think the default of
> 1.7 will work fine. But what about cases where people are setting the version
> to 1.8 ? They may want to test the newer js features in 1.8 possibly. Either
> way, this is not a common problem anymore.

Yeah, the 1.8 thing is an issue. I just don't think there's a good way to say "we want the newest JS version", or even "we want a specific JS version", at runtime. We can't enforce a specific version at build time because we don't know what versions the app we'll run in will support. :-(

Marking this WFM for now...