On May 7, 2008, at 1:33 PM, Boris Zbarsky wrote:
Scott Shattuck wrote:
1) The script is running at a file:// URI
I believe it's key that future specification work keep in mind that
this isn't the rare case it used to be, it's one definition of "run
offline".
While true, note that Gecko also supports actual running offline of
http URIs, where you actually have a hostname to use for security
checks. This seems like a bette way forward to me, if at all
possible.
The fundamental problem with using file:// as you describe is the
lack of such compartmentalization. Gecko 1.9 will try to sandbox
files from each other somewhat, but it's likely to not be perfect
and likely to break some attempts to "use the browser as a file-
launched VM".
it's also important to maintain
the ability of enterprises and others to create file-launched
applications that are simply leveraging the browser as an easier-to-
develop for VM.
This is why you can call enablePrivilege from file:// right now...
I guess I'm not sure how your point relates to the text you quoted,
other than as agreement with that exception to the general "can't
prompt" policy.
-Boris
I'm not trying to be difficult, far from it. I'm just trying to truly
understand where you see things headed in this regard.
In the past I've built several applications which simply require the
user to double click an index.html file on their desktop. This has
worked just fine, until recently. Recent mozilla builds have actually
started to fail to work with this approach because in my case the top-
level index.html file loads a frameset document containing a
javascript file which does the real work of booting the application
and that lower-in-the-directory-structure js file's location appears
to be used as the root of the "accessible file tree" rather than the
original index.html file used to launch the application. I've already
had to rework the directory structure of the applications in question
to work around this issue. Big pain for me, big pain for my customers.
What I'm hearing in this thread is that you're suggesting this will
get worse -- perhaps to the point that it will stop working
altogether. That file: urls launched in this fashion might not work
due to an inability to somehow decide what's safe and what's not. That
I'll have had to have initially run the app from a local or remote web
server where my a) HTML5-compliant browser b) plugin-enhanced browser,
c) desktop "single-site browser" etc. can cache the pages. (Scenarios,
I might point out, which require precisely what my user community does
not want -- installation of new components on desktop machines...part
of the point of using a browser is to reduce/eliminate this particular
administrative nightmare).
People are used to double-clicking on index.html, Mozilla is already
breaking that model. I'm not sure I can recommend any particular
direction, but I can certainly lodge my concern that the current
direction doesn't appear to be in the best interest of the end user
whose got double-click hard-wired into their mouse hand.
ss
