Closed Bug 469192 Opened 16 years ago Closed 15 years ago

After visiting file:/// location, globalStorage['localhost'] doesn't work at file://localhost/ locations

Categories

(Core :: DOM: Core & HTML, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: sky, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20081211 Minefield/3.2a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20081211 Minefield/3.2a1pre

globalStorage['localhost'] generally seems to be very finicky, in working.  I can reproduce reliably the 'steps to reproduce' but I think there's something more going on.  I can't reproduce a way to start make it working again, but I think opening an invalid file:///dummy location, somehow helps.

Basically, whenever at a page file://localhost/ ..., globalStorage['localhost'] info should be available.

Reproducible: Always

Steps to Reproduce:
1. Save http://www.columbia.edu/~sky/bugs/firefox/globalstorage.html to your hard drive.
2. File->Open and visit it at file:///..../globalstorage.html
(The web page will redirect itself to file://localhost/..../globalstorage.html)
3. You will get an error message alert that there is no access to globalStorage['localhost'].
4. Close the browser, and reopen it.
5. Explicitly, open file://localhost/..../globalstorage.html
6. Set the login with the button on the page.  Confirm that closing and opening the browser by repeating #5, #6 saves the login from the last session.
7. Close the browser and reopen it, again.
8. Visit a different local file with file:///...../somefile.html (has to actually exist--not a file not found)
9. Explicitly open file://localhost/..../globalstorage.html again, and note that we see #3 behavior instead of #6.
Actual Results:  
Step #3 is different than #6.
Step #9 is different than #6.
They should all be the same as step #6.

Expected Results:  
Results at steps #3, #9 should be the same as at #6.
I'm a little surprised that file://localhost/ does something. The host part of the file:// URI scheme should always be empty. I don't know what this means for the globalStorage object, though, since that seems to be entirely related to web domains. Does globalStorage distinguish between http:// and https://, which are technically different security domains?
Component: Security → DOM
QA Contact: toolkit → general
(In reply to comment #1)
> I'm a little surprised that file://localhost/ does something. The host part of
> the file:// URI scheme should always be empty. I don't know what this means for
> the globalStorage object, though, since that seems to be entirely related to
> web domains. 
I started playing around after reading this thread/comment:
http://forums.mozillazine.org/viewtopic.php?f=38&t=966785#p5083655

I certainly think there SHOULD be a way to use globalStorage (or localStorage, when it comes) for local files (including at file:///).  Otherwise, how to make real offline apps?
I _guess_ it's WONTFIX and the recommendation is to use localStorage, which, as far as I can see, works fine for file:/// documents? See also bug 407839.
Er, I was confused, localStorage doesn't work in file:/// documents (which is, as far as I can see is bug 507361?).
I think this is a wontfix now, since there's no such thing, anymore as 'file://localhost/' urls which are now redirected to 'file:///'
This does make localStorage working in file:/// more urgent since a previous way of using globalStorage (by including the 'localhost' in the url) is now disabled.

Count me as one developer who has deployed applications that no longer work at all because of this.
OK, I thought the file://localhost/ URLs redirected only for me. If they're indeed gone, this is the same as bug 507361.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.