Changes between Initial Version and Version 1 of Ticket #7457, comment 2


Ignore:
Timestamp:
04/11/2019 05:35:15 PM (6 months ago)
Author:
sebastian
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #7457, comment 2

    initial v1  
    22> We should be probably either calling `Prefs.set` explicitly and waiting for the returned Promise to resolve before reading the value back from `browser.local.storage`, or read the value back using the preference getters. 
    33 
    4 If we call `Prefs.set()` directly, the code path of the setter wouldn't be tested. If we use the getter, we don't test whether the data are actually persisted. Maybe the best approach would be to retry `browser.storage.get()` for up to 1s (or something like that). 
     4If we call `Prefs.set()` directly, the code path of the setter wouldn't be tested. If we only test the getter, we don't test whether the data are actually persisted. Maybe the best approach would be to retry `browser.storage.get()` for up to 1s (or something like that). 
    55 
    66> Furthermore, the test in question seems misleading and pointless. It's described as "Property-wise modification", as opposed to the previous test "Object pref (complete replacement)". While it does assign properties on the preference's value, it actually only then stores the value by turning the Object to a JSON string and back, before reassigning the whole thing! 
    77 
    8 That is a pattern we use in our actual source code (when saving the `notificationdata` preference). It is a hack, but unless we assign a new object, we don't write preference to storage. 
     8That is a pattern we use in our actual source code (when saving the `notificationdata` preference). It is a hack, but unless we assign a new object, the preference isn't written to storage.