Closed
Bug 621365
Opened 15 years ago
Closed 15 years ago
localstorage session-only determination in parent process is broken via IPC
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
| Tracking | Status | |
|---|---|---|
| fennec | 2.0+ | --- |
People
(Reporter: jdm, Unassigned)
References
Details
Attachments
(1 file)
|
17.82 KB,
patch
|
mayhemer
:
review+
|
Details | Diff | Splinter Review |
The parent's DOMStorageImpl mSessionOnly var is only determined at creation, which is very incorrect. I believe we need to forward the child's mSessionOnly with each operation we perform.
| Reporter | ||
Comment 1•15 years ago
|
||
This should block, as it breaks the expected storage lifetime of localstorage instances used with session cookies,
tracking-fennec: --- → ?
| Reporter | ||
Comment 2•15 years ago
|
||
Attachment #499704 -
Flags: review?(honzab.moz)
Comment 3•15 years ago
|
||
I had an idea to move check for session-only to the chrome process completely (send just the subject URI to inspect it by the storage implementation later) but I didn't measure any performance benefit.
I'll review your patch soon.
Comment 4•15 years ago
|
||
Comment on attachment 499704 [details] [diff] [review]
Forward child session-only status to parent.
> sync protocol PStorage
> sync GetKeys(bool callerSecure)
> returns (nsString[] keys);
I am not sure of this method if it also needs to pass sessionOnly arg. If so, then it is probably a different bug, and probably present before remoting dom storage.
>+ void ForceSessionOnly(bool aSessionOnly);
Maybe rather just SetSessionOnly ?
r=honzab
Attachment #499704 -
Flags: review?(honzab.moz) → review+
Updated•15 years ago
|
tracking-fennec: ? → 2.0+
| Reporter | ||
Comment 5•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
| Assignee | ||
Updated•7 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•