Re: File IO...

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

Received on Wednesday, 7 May 2008 20:00:37 UTC