In the implementation of Storage.has(key), we should check against null instead of undefined to see if a key exists in the storage. - #125
Yutao Huang (yutao-huang) wants to merge 3 commits into
Conversation
…ll instead of undefined to see if a key exists in the storage. According to the W3C standard (https://www.w3.org/TR/webstorage/#dom-storage-getitem), "... If the given key does not exist in the list associated with the object then this method must return null..."
|
Adding the related issue: #126 |
Michael Zlatkovsky (Zlatkovsky)
left a comment
There was a problem hiding this comment.
Should it check for both null and undefined, for safety?
|
Michael Zlatkovsky (@Zlatkovsky) thanks for the approval! I've verified the behavior of |
|
Yutao Huang (@yutao-huang) , it comes down to implementation details. For example, depending on whether the underlying implementation uses I expect that's how the bug found its way here in the first place -- that Bhargav had originally had one implementation, then changed it out for another, and suddenly an older assumption about undefined was no longer true. While null and undefined are semantically different, I would argue that they are mostly the same for purposes of this class. So I think it's better to check for both rather than have it only do one, and then risk an internal-implementation change breaking the outer contract. |
|
As for my approval -- note that you still will need someone else like Sudhi Ramamurthy (@sumurthy) to actually merge in the changes. I don't have any admin rights on this repo, so I don't know if my "approval" means much per se. |
|
Michael Zlatkovsky (@Zlatkovsky) , gotcha, that makes sense. I added the check for safety. I'll ping Sudhi Ramamurthy (@sumurthy) to get some help. Thanks! |

According to the W3C standard (https://www.w3.org/TR/webstorage/#dom-storage-getitem):
In the existing code,
this.get(key) !== undefinedwould always betrueeven when the key doesn't exist. In this case,this.get(key)actually returnsnull.This incorrect behavior is also impacting things like
authenticator.endpoints.has(...), which always mistakenly returnstruefor an actually not registered endpoint.