New meaning of sandboxed in 1.7R4

[Tim Schaub]

In 1.7R3, I could use installRequire with sandboxed true and still
require modules that used relative identifiers to require one another.
With the latest, this no longer works. I've added detail to
https://github.com/mozilla/rhino/issues/44 and committed a failing
test to my fork [1].

I can see why this is happening, but it isn't helping me understand
what sandboxed really means. Is it intended to mean that modules
cannot require one another with relative identifiers ("./like/this")?

Thanks for any feedback,
Tim

[1] https://github.com/tschaub/rhino/commit/27f923f7ae81b0d56e22312656db2027188656f8

[Hannes Wallnöfer]

That's definitely a bug. Trying to find out what's going on and
writing more tests.

Hannes

2012/5/27 Tim Schaub <tim.s...@gmail.com>:

[Hannes Wallnöfer]

I think your understanding of "sandboxed" mode is correct, btw. It
means that modules can only be loaded from within the given module
root URLs.

Hannes

2012/5/28 Hannes Wallnöfer <han...@gmail.com>:

[Tim Schaub]

Thanks for looking into it Hannes.

I'm also seeing what may be a related issue trying to load modules
from a jar. I get a failure on the first require that uses a relative
module identifier. A require("./sub/mod") results in:

Wrapped java.net.MalformedURLException: no protocol: base/sub/mod.js

While debugging and running tests, my modules are being loaded from a
build dir, so I can't immediately see where this is coming from, but
things are definitely failing when I deploy modules in a jar. I'll
try to get set up to debug and will provide more detail in a ticket.

Tim

[Hannes Wallnöfer]

The bug is fixed now:

https://github.com/mozilla/rhino/commit/16f2f34e387ff5f5614999ba46d87fed59a00844

2012/5/29 Tim Schaub <tim.s...@gmail.com>:

>
> I'm also seeing what may be a related issue trying to load modules
> from a jar.  I get a failure on the first require that uses a relative
> module identifier.  A require("./sub/mod") results in:
>
>    Wrapped java.net.MalformedURLException: no protocol: base/sub/mod.js

Yes, this error had the same cause of base URIs not being carried
along with relative module ids. It is fixed by the last commit as
well.

As I wrote in my closing comment on the issue tracker, the reason
these problems were not triggered by the existing test for relative
IDs was that modules were loaded first through their absolute ID and
only then by relative ID, and the sandbox check is only performed when
a module is loaded for the first time. This is now fixed as well so
the existing test would trigger these bugs.

Thanks for reporting!

Hannes

[Tim Schaub]

Thanks for addressing this Hannes. All working well on my end again.

Tim