Received: by 10.141.22.14 with SMTP id z14mr817549rvi.5.1272923590134;
        Mon, 03 May 2010 14:53:10 -0700 (PDT)
X-BeenThere: envjs@googlegroups.com
Received: by 10.141.13.11 with SMTP id q11ls26564737rvi.3.p; Mon, 03 May 2010 
	14:53:09 -0700 (PDT)
Received: by 10.141.124.18 with SMTP id b18mr1068993rvn.29.1272923589062;
        Mon, 03 May 2010 14:53:09 -0700 (PDT)
Received: by 10.141.124.18 with SMTP id b18mr1068992rvn.29.1272923589034;
        Mon, 03 May 2010 14:53:09 -0700 (PDT)
Return-Path: <g...@mcn.org>
Received: from smtp1.mcn.org (smtp1.mcn.org [216.150.240.85])
        by gmr-mx.google.com with ESMTP id 18si895715pzk.2.2010.05.03.14.53.08;
        Mon, 03 May 2010 14:53:09 -0700 (PDT)
Received-SPF: pass (google.com: best guess record for domain of g...@mcn.org designates 216.150.240.85 as permitted sender) client-ip=216.150.240.85;
Received: from [72.169.129.21] (helo=[10.201.2.104])
	by smtp1.mcn.org with esmtpa (Exim 4.71)
	(envelope-from <g...@mcn.org>)
	id 1O93ZW-0002va-5G; Mon, 03 May 2010 14:53:07 -0700
Message-ID: <4BDF45B2.9040908@mcn.org>
Date: Mon, 03 May 2010 14:52:50 -0700
From: "Glen E. Ivey" <g...@mcn.org>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: envjs@googlegroups.com
Subject: Re: [env-js] Opinions on new tests for window.location= ?
References: <4BDF0960.9050007@mcn.org> <m2qb99491f31005031306n70d62bc3tecdc5dbc2445bc9e@mail.gmail.com>
In-Reply-To: <m2qb99491f31005031306n70d62bc3tecdc5dbc2445bc9e@mail.gmail.com>
X-Enigmail-Version: 0.95.7
X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: 
	best guess record for domain of g...@mcn.org designates 216.150.240.85 as 
	permitted sender) smtp.mail=...@mcn.org
X-Original-Sender: g...@mcn.org
Reply-To: envjs@googlegroups.com
Precedence: list
Mailing-list: list envjs@googlegroups.com; contact envjs+owners@googlegroups.com
List-ID: <envjs.googlegroups.com>
List-Post: <http://groups.google.com/group/envjs/post?hl=en_US>, 
	<mailto:envjs@googlegroups.com>
List-Help: <http://groups.google.com/support/?hl=en_US>, <mailto:envjs+help@googlegroups.com>
List-Archive: <http://groups.google.com/group/envjs?hl=en_US>
Sender: envjs@googlegroups.com
List-Subscribe: <http://groups.google.com/group/envjs/subscribe?hl=en_US>, 
	<mailto:envjs+subscribe@googlegroups.com>
List-Unsubscribe: <http://groups.google.com/group/envjs/subscribe?hl=en_US>, 
	<mailto:envjs+unsubscribe@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Inline....

chris thatcher wrote:
> I agree its not acceptable to restrict use of window.open or
> window.location.  They should be able to be used as part of a script
> that allows the user to navigate the web at their discretion.

Good.  So we're not going to accept something like my old "you can only
do window.location= once in the original window" restriction as a "done"
state going forward.

> I'm not exactly sure what you mean by loading protocol

I mean the convention of starting env.js through code like:
  load("path-to/env.rhino.js");
  Envjs();
  Envjs.wait();

Right now, I'm thinking that the easiest way to get the window object
arrangement "right" prior to any "user" code executing will be to have
env.js itself be what is named for loading on the Java/Rhino command
line, with the user JS or HTML files being named as arguments that
env.js will process.  Obviously, that would replace code snippets like
the above and necessitate people using env.js to change their
environments, but earlier compromises to allow the env.js load sequence
to remain the same were obviously unsatisfying.

> but I believe the
> following is possible and not overly ambitious or overly restrictive:
> [....]
> Does that sound reasonable?  I can help point to the rhino api methods I
> think could help achieve that.

Hmmmm.....  This is well outside anything I was considering.  I see the
motivation for this behavior and how implementing it could be
approached, but it isn't something I have any use for and isn't
something that improves env.js' browser compatibility, so I'd rather
leave it to someone else who's going to use this functionality to add it
after I've got the basic (browser-compatible) behaviors back in place.

Also, you might want to reread the excellent stuff Steven Parkes wrote
in the [env-js] email thread "Help with Rhino and Envjs.proxy and
__context__" about the state of the scope in a piece of JavaScript for
the statements that occur after a window.location= assignment.  I'm
hoping to get this behavior fully spec-compliant this time around, and
would be disappointed if implementing something like this pushed us
farther from spec compliant (without some kind of "mode" switch to
control the behavior a user's code expects).


Does this make it clearer what kind of feedback/direction I was looking
for, and the extent of the kind of implementation work I'm getting into?

Thanks for the reply,
    glen


- --
gleneivey on Skype, Y!IM, AIM, Twitter, Facebook, GitHub
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvfRbIACgkQkocwxK1irU2HzACbBGfq1hje7bZqa7bRpcolLAYQ
zA0An0AoYd2KLModw3yQd4p1aZgRhXRg
=THkn
-----END PGP SIGNATURE-----

-- 
You received this message because you are subscribed to the Google Groups "Env.js" group.
To post to this group, send email to envjs@googlegroups.com.
To unsubscribe from this group, send email to envjs+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/envjs?hl=en.