a global object to store data [eg store data as property of Navigator object]

RESOLVED DUPLICATE of bug 163645

Status

()

Core
DOM: Core & HTML
P3
enhancement
RESOLVED DUPLICATE of bug 163645
17 years ago
14 years ago

People

(Reporter: Wolfgang Schwarz, Unassigned)

Tracking

({helpwanted})

Trunk
Future
helpwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
In NN4, you could store any data as property of the navigator object, where it 
remained throughout the entire Communicator session. This was extremely useful 
as one often needs certain data on several pages, and cookies are a very 
inconvenient solution for that (not only because many people have disabled them, 
you also cannot store, say, window references, and can't access their content 
from other domains).

The navigator trick has been jettisoned in Mozilla, which is right because it 
certainly was a security issue. But it would be very good to have a proper 
solution for that. Here is a suggestion: 

Provide a global object sessionData with the following methods:

  void set(string id, object data)
     allocate memory and save data

  object get(string id)
     return the data corresponding to the id

  number getMemoryLeft(string id)
     return the memory that is still available for the id
     (could be limited to e.g. 5 KB per ID)

and a property:

  number status
     reflecting whether the last action was succesful or, if not, 
     what kind of problem occured.

sessionData should be accessible from _all_ browser instances and from all 
domains. It would suffice that each domain can only use one ID.
Of course, sessionData must not be enumerable: only if you know the ID you can 
get the corresponding data.

To save memory space, every use of getData should delete the retrieved data from 
sessionData.

Comment 1

17 years ago
Looks to me to be an enhancement bug.
Severity: normal → enhancement

Comment 2

17 years ago
setting new
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

17 years ago
Status: NEW → ASSIGNED
OS: Windows 98 → All
Hardware: PC → All
Target Milestone: --- → mozilla1.1
Setting milestone to mozilla1.1, that's the earlies when this could happen
unless there's a good reason to do it earlier.
Setting milestone to Future to keep this off my current buglist.
Target Milestone: mozilla1.1 → Future
Keywords: dom0

Comment 5

17 years ago
I think there should be a fresh object for each domain, since it probably
wouldn't be very hard to guess application IDs.

For allowing two domains to share an application object (or access each other's
application object), see bug 64886, [RFE] Ability to define friend URL for Same
Origin security model.
Keywords: dom0
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Status: ASSIGNED → NEW

Updated

15 years ago
Keywords: helpwanted
Summary: [FEATURE] a global object to store data → a global object to store data [eg store data as property of Navigator object]
Duping to the bug which fixed this.  The navigator object now behaves closer to
Netscape 4 (and as close as it will ever get in Mozilla).  As long as the pages
accessing window.navigator have the same origin, you are kosher.

*** This bug has been marked as a duplicate of 163645 ***
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.