The default bug view has changed. See this FAQ.

Some settings for add-ons aren't being migrated when we change database schemas

RESOLVED FIXED in Firefox 8

Status

()

Toolkit
Add-ons Manager
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: mossop, Assigned: mossop)

Tracking

({dataloss})

8 Branch
mozilla10
dataloss
Points:
---

Firefox Tracking Flags

(firefox8 fixed, firefox9 fixed)

Details

(Whiteboard: [qa+])

Attachments

(1 attachment)

(Assignee)

Description

6 years ago
applyBackgroundUpdates, sourceURI and resourceURI are getting lost whenever we update the DB schema
(Assignee)

Comment 1

6 years ago
Created attachment 567776 [details] [diff] [review]
patch rev 1

Add migration for these fields and a test for it.
Attachment #567776 - Flags: review?(bmcbride)
Comment on attachment 567776 [details] [diff] [review]
patch rev 1

Review of attachment 567776 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.

(Oh hell, I'm bitrotten already)
Attachment #567776 - Flags: review?(bmcbride) → review+
(Assignee)

Comment 3

6 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/2739199a5bbd
Whiteboard: [inbound]
https://hg.mozilla.org/mozilla-central/rev/2739199a5bbd
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
(Assignee)

Updated

6 years ago
Keywords: dataloss
(Assignee)

Comment 5

6 years ago
Comment on attachment 567776 [details] [diff] [review]
patch rev 1

Bug 693743 does a schema change which will cause this set of dataloss to happen again so I'd very much like to take this patch as well (also the patch in bug 693743 will have to be changed without it), it is low risk enough that I think it's ok to take on beta.
Attachment #567776 - Flags: approval-mozilla-beta?
Attachment #567776 - Flags: approval-mozilla-aurora?

Comment 6

6 years ago
---------------------------------[ Triage Comment ]---------------------------------

Approving for 8beta and 9aurora as this is a dataloss bug that will be triggered again by bug 693743. The patch looks to be low risk and contained.

Please land ASAP.

Updated

6 years ago
Attachment #567776 - Flags: approval-mozilla-beta?
Attachment #567776 - Flags: approval-mozilla-beta+
Attachment #567776 - Flags: approval-mozilla-aurora?
Attachment #567776 - Flags: approval-mozilla-aurora+
(Assignee)

Updated

6 years ago
Target Milestone: --- → mozilla10
(Assignee)

Comment 7

6 years ago
https://hg.mozilla.org/releases/mozilla-beta/rev/690543d90329
https://hg.mozilla.org/releases/mozilla-aurora/rev/4d7b3566bd13
status-firefox8: --- → fixed
status-firefox9: --- → fixed
Are there any specific instructions for QA to verify this fix?
Whiteboard: [qa?]
(Assignee)

Comment 9

5 years ago
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #8)
> Are there any specific instructions for QA to verify this fix?

Run Firefox 7 and install an add-on, in its details change its auto-update setting to something other than default. Update to Firefox 8 and check that that setting is retained.
Whiteboard: [qa?] → [qa+]
I've verified this on Win 7 32 and 64 updating Firefox 7.0.1 with Adblock Plus 1.3.10 to Firefox 8.0.1. The addon was initially set with automatic updates ON, but after the update has changed to OFF. If automatic updates is set to default or OFF, the setting remains the same after the update.
I take it this bug can be marked VERIFIED then? Paul, Dave, please confirm.
No, it is not the right scenario. Dave?
(Assignee)

Comment 13

5 years ago
(In reply to Paul Silaghi [QA] from comment #12)
> No, it is not the right scenario. Dave?

No this is not correct, please file a new bug with specific STR
New bug 705631 logged. Can I mark this as verified fixed now ?
(Assignee)

Updated

5 years ago
Depends on: 705631
Dave, can this be marked verified fixed based on Paul's testing? Is there something else we can do? Should this be retested given the dependency being fixed?
Whiteboard: [qa+] → [qa?]
(Assignee)

Comment 16

5 years ago
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #15)
> Dave, can this be marked verified fixed based on Paul's testing? Is there
> something else we can do? Should this be retested given the dependency being
> fixed?

I would re-test with the fix from the other bug too and then verify.
Whiteboard: [qa?] → [qa+]
Fix for bug #705631 was pushed only for m-c and cannot be verified in beta.
Dave, will the fix for bug 705631 ever make it into Firefox 9? If not, I don't think we will be able to retest this as requested in comment 16.
(Assignee)

Comment 19

5 years ago
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #18)
> Dave, will the fix for bug 705631 ever make it into Firefox 9? If not, I
> don't think we will be able to retest this as requested in comment 16.

You can re-test with trunk though right? I'm not sure it's worth trying to push the fix for this down to beta.
Well we can, Dave. Though this bug was fixed on Firefox 8 and 9 -- that's where we are trying to verify the fix. Testing on trunk is fine for bug 705631, but I don't see how that enables us to mark this bug VERIFIED for 8 and 9.
(Assignee)

Comment 21

5 years ago
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #20)
> Well we can, Dave. Though this bug was fixed on Firefox 8 and 9 -- that's
> where we are trying to verify the fix. Testing on trunk is fine for bug
> 705631, but I don't see how that enables us to mark this bug VERIFIED for 8
> and 9.

Well I guess the point is that it isn't fully fixed for 8 and 9.
Since we already verified this once, I'm thinking we can mark this VERIFIED and we can retest it on bug 705631 if/when it gets ported to Aurora/Beta. Does this sound reasonable?
I verified the fix of bug #705631 on Nightly and it worked as expected.
You need to log in before you can comment on or make changes to this bug.