1270044 - Should it be possible to null out window.IndexedDB?

Status: RESOLVED INVALID

(Core :: Storage: IndexedDB, defect)

Description

[Jukka Jylänki]

I'm writing a test harness for a page, and trying to simulate testing if IndexedDB is not available.

However I noticed that in current Nightly, if one types in

window.indexedDB = null;
window.indexedDB

in console, the second line will still return IDBFactory, and the first line did not have any effect. Should it be possible to assign null over indexedDB?

Comment 1

[Boris Zbarsky [:bzbarsky]]

Per spec, this should not work, since it's a readonly property.  Of course you can do one of:

  delete window.indexedDB; // More like actual lack of support.

or

  /* More like doing window.indexedDB = null in a browser where it's not supported at all */
  Object.defineProperty(window, "indexedDB", { writable: true, configurable: true, value: null });

Comment 2

[Jukka Jylänki]

Great help! delete window.indexedDB works nicely.

Btw, is there some kind of design trend or rationale here? Since one can replace console object and performance object nicely via assignment, I wonder why indexedDB was specced differently as readonly? Accidental result of how things just came to be? Or is there a shift towards making new web APIs readonly properties in general? Just wondering if there's some specific history to this?

Comment 3

[Boris Zbarsky [:bzbarsky]]

> Btw, is there some kind of design trend or rationale here?

Yes.  Things that don't have meaningful setters are generally readonly unless required otherwise for backwards compat reasons.

> Since one can replace console object and performance object nicely via assignment

Console is marked [Replaceable] for compat reasons, because lots of sites set up their own things there back in the days befoer browsers were shipping it.

Same thing for performance: lots of sites were using that as a global variable name, etc.  So making it non-replaceable would have broken them.

> I wonder why indexedDB was specced differently as readonly? 

Other way around.  It's "console" and "performance" that were specced with the weird [Replaceable] behavior.  It wasn't an issue for "indexedDB" because that wasn't a commonly used variable name before the API was added.

> Or is there a shift towards making new web APIs readonly properties in general?

Nothing new about it.  "document" is readonly on Window (and actually much more strongly so than "indexedDB"; you can't even defineProperty or delete it; same thing for "window" itself).  "history" behaves like "indexedDB" and is ... much older.  ;)  Same for "closed" Properties on every non-window API are readonly unless assignment to them actually means something.

On window in particular, a number of APIs are explicitly marked [Replaceable] because they have names that would otherwise collide with variables people commonly try to use in their scripts, which would cause problems.  And for new APIs on Window that have names that might plausibly with existing variable names, [Replaceable] is generally a good idea for compat reasons.

Of course it also has its drawbacks: if some script you load does "var performance = 5" in global scope, suddenly you can't get at the performance object anymore in any other scripts on the page....

Comment 4

[Jukka Jylänki]

Oh, super insightful and makes sense, thanks!