The default bug view has changed. See this FAQ.

`localStorage.clear()` doesn't actually delete its properties

RESOLVED FIXED in mozilla1.9.2

Status

()

Core
DOM
P2
normal
RESOLVED FIXED
8 years ago
4 years ago

People

(Reporter: Juriy "kangax" Zaytsev, Assigned: mayhemer)

Tracking

({html5, testcase})

Trunk
mozilla1.9.2
html5, testcase
Points:
---
Bug Flags:
blocking1.9.2 +

Firefox Tracking Flags

(status1.9.2 beta4-fixed)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

`localStorage` supports short accessor notation (as an alternative to `getItem`/`setItem`): 

localStorage.foo = 'bar';
localStorage.foo; // 'bar'

It also supports `clear()` method, which as per current "Web Storage" specs draft (http://www.w3.org/TR/webstorage/):

"... must atomically cause the list associated with the object to be emptied of all key/value pairs, if there are any. If there are none, then the method must do nothing."

What looks like a bug is that even after `clear()`, keys are still "present" in `localStorage`:

localStorage.foo = 'bar';
localStorage.clear();
'foo' in localStorage; // true

Is this an expected behavior? 

Note that the last statement returns `false` in at least WebKit and IE8 (and allows to check for presence of a value without resorting to a more verbose - `getItem(key) !== null`).

Thank you.

Reproducible: Always

Comment 1

8 years ago
The spec also says "The names of the supported named properties on a Storage  object are the keys of each key/value pair currently present in the list associated with the object.", so this looks like a bug.

See the URL field for testcase.

Confirmed in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20090919 Minefield/3.7a1pre
Status: UNCONFIRMED → NEW
Component: General → DOM: Mozilla Extensions
Ever confirmed: true
Keywords: html5, testcase
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
(Assignee)

Updated

8 years ago
Assignee: nobody → honzab.moz
(Assignee)

Updated

8 years ago
Flags: blocking1.9.2?
(Assignee)

Comment 2

8 years ago
From jst on IRC: "I think that'd be a matter of finding the XPConnect wrapper for the localStorage object when calling clear, and calling JS_ClearScope() on its JSObject"
I think we should block on this web compatibility bug for 1.9.2.
Flags: blocking1.9.2? → blocking1.9.2+
OS: Mac OS X → All
Priority: -- → P2
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.2
(Assignee)

Comment 4

8 years ago
Created attachment 409678 [details] [diff] [review]
v1 [Checkin comment 6]
Attachment #409678 - Flags: review?(jst)
Comment on attachment 409678 [details] [diff] [review]
v1 [Checkin comment 6]

r+sr=jst
Attachment #409678 - Flags: superreview+
Attachment #409678 - Flags: review?(jst)
Attachment #409678 - Flags: review+
(Assignee)

Comment 6

8 years ago
Comment on attachment 409678 [details] [diff] [review]
v1 [Checkin comment 6]

http://hg.mozilla.org/mozilla-central/rev/5df9f71b9e98
Attachment #409678 - Attachment description: v1 → v1 [Checkin comment 6]
(Assignee)

Updated

8 years ago
Attachment #409678 - Flags: approval1.9.2?
(Assignee)

Updated

8 years ago
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Comment on attachment 409678 [details] [diff] [review]
v1 [Checkin comment 6]

(this is a blocker, doesn't need explicit approval, please land ASAP)
Attachment #409678 - Flags: approval1.9.2?
(Assignee)

Comment 8

8 years ago
Created attachment 412613 [details] [diff] [review]
as landed on 1.9.2 [Checking comment 8]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/247cda75bc87
(Assignee)

Updated

8 years ago
status1.9.2: --- → final-fixed
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.