Closed Bug 1634756 Opened 2 years ago Closed 2 years ago

ExtensionSettingsStore does not handle addon.installDate being null

Categories

(WebExtensions :: Themes, defect, P1)

defect

Tracking

(firefox-esr68 unaffected, firefox76 unaffected, firefox77 wontfix, firefox78 fixed)

RESOLVED FIXED
mozilla78
Tracking Status
firefox-esr68 --- unaffected
firefox76 --- unaffected
firefox77 --- wontfix
firefox78 --- fixed

People

(Reporter: robwu, Assigned: robwu)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

While reading the change from bug 1583844, I was wondering whether there are any consumers of an addon's .installDate or .updateDate that use the value without checking whether it is non-null.

There are some occurrences of addon.installDate.valueOf() in ExtensionSettingsStore.jsm.

A couple in getLevelOfControl, which is probably not that big of a deal (in the worst case, an error will be logged, when an extension is uninstalled while the .get method of a settings API is in progress).

There are some uses in ExtensionSettingsStore.addSetting, which has a few callers that could potentially trip terribly over a runtime error.

Attachment #9145099 - Attachment description: Bug 1634756 - Add null check of addon.installDate in ExtensionSettingsStore → Bug 1634756 - Ensure that installDate is never null for non-null dates

Set release status flags based on info from the regressing bug 1583844

Severity: -- → S3
Priority: -- → P1

Rob, do you have an update on this bug and a potential uplift of a fix to beta? Thanks

Flags: needinfo?(rob)

I'll get back to this later this week or next week.

Keeping ni? for visibility in my ni queue.

Attachment #9145099 - Attachment description: Bug 1634756 - Ensure that installDate is never null for non-null dates → Bug 1634756 - Ensure that installDate is never null, and let updateDate fall back to installDate
Pushed by rob@robwu.nl:
https://hg.mozilla.org/integration/autoland/rev/d3a0c51da4a9
Ensure that installDate is never null, and let updateDate fall back to installDate r=mixedpuppy

During the review we have established that .installDate should never be unset, so .installDate is never null (despite bug 1583844). There are some contrived edge cases where it would be a problem, but I'm not too concerned with that.

This bug fixes bug 1583844 in the "proper" way, but that bug is not critical.

Since the absence of the patch is not expected to cause significant issues, I'll just let it ride the trains instead of uplifting it.

Flags: needinfo?(rob)
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.