1185613 - Default permissions aren't loaded if permission manager v5 migration fails

Status: RESOLVED DUPLICATE of bug 1185343

(Core :: Permission Manager, defect)

Description

[Matthew N. [:MattN]]

[Tracking Requested - why for this release]: Breaks default permissions for users which include things like add-on installation, self-support/heartbeat, UITour, etc. [1]

> [9040] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /builds/slave/m-cen-m64-d-000000000000000000/build/src/extensions/cookie/nsPermissionManager.cpp, line 914

which refers to [2]

I'm guessing the migration has already happened on this profile and is happening again. We could probably be a bit more graceful here instead of doing an early return at that point e.g. `break` instead since there is other code below the migration code e.g. ImportDefaults(); that should run regardless.

[1] https://mxr.mozilla.org/mozilla-central/source/browser/app/permissions
[2] https://mxr.mozilla.org/mozilla-central/source/extensions/cookie/nsPermissionManager.cpp?rev=176f0a5ce9c7&mark=914#910

Comment 1

[(no longer active)]

Hmm, we should first figure out why that statement fails.  Do you have a permissions.sqlite file that reproduces this issue?

Comment 2

[Matthew N. [:MattN]]

I think the migration had already happened and Alex downgraded to an earlier Firefox.

Comment 3

[Alex Gibson [:agibson]]

(In reply to Matthew N. [:MattN] from comment #2)
> I think the migration had already happened and Alex downgraded to an earlier
> Firefox.

Yep, I downgraded to Firefox 35 to test something, which i think is what likely triggered the issue.

Comment 4

[(no longer active)]

Michael, can you see if you can reproduce this after a downgrade, please?

Comment 5

[(no longer active)]

(One issue that I see by code inspection is that we never check for moz_hosts_v4's existence, so what might be happening is that table existing from a previous upgrade, and a second one breaking due to the table we're renaming too already existing.)

Comment 6

[Nika Layzell [:nika] (ni? for response)]

(In reply to Ehsan Akhgari (not reviewing patches, not reading bugmail, needinfo? me!) from comment #5)
> (One issue that I see by code inspection is that we never check for
> moz_hosts_v4's existence, so what might be happening is that table existing
> from a previous upgrade, and a second one breaking due to the table we're
> renaming too already existing.)

That's definitely a problem, and I definitely should handle that case. I'll do the check in a few minutes.

Comment 7

[Nika Layzell [:nika] (ni? for response)]

This shouldn't be a problem anymore once bug 1185343 lands.

Comment 8

[Alex Gibson [:agibson]]

Updated to Nightly 42.0a1 (2015-07-22), and it seems to have fixed my issue. Thanks, all!