Closed
Bug 1185613
Opened 9 years ago
Closed 9 years ago
Default permissions aren't loaded if permission manager v5 migration fails
Categories
(Core :: Permission Manager, defect)
Core
Permission Manager
Tracking
()
RESOLVED
DUPLICATE
of bug 1185343
People
(Reporter: MattN, Unassigned)
Details
(Keywords: regression)
[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
Flags: needinfo?(michael)
Comment 1•9 years ago
|
||
Hmm, we should first figure out why that statement fails. Do you have a permissions.sqlite file that reproduces this issue?
Flags: needinfo?(MattN+bmo)
Reporter | ||
Comment 2•9 years ago
|
||
I think the migration had already happened and Alex downgraded to an earlier Firefox.
Flags: needinfo?(MattN+bmo) → needinfo?(agibson)
Comment 3•9 years ago
|
||
(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.
Flags: needinfo?(agibson)
Comment 4•9 years ago
|
||
Michael, can you see if you can reproduce this after a downgrade, please?
Comment 5•9 years ago
|
||
(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•9 years ago
|
||
(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.
Flags: needinfo?(michael)
Updated•9 years ago
|
Flags: needinfo?(michael)
Comment 7•9 years ago
|
||
This shouldn't be a problem anymore once bug 1185343 lands.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(michael)
Resolution: --- → DUPLICATE
Updated•9 years ago
|
No longer blocks: 1165263
status-firefox41:
unaffected → ---
status-firefox42:
affected → ---
tracking-firefox42:
? → ---
Comment 8•9 years ago
|
||
Updated to Nightly 42.0a1 (2015-07-22), and it seems to have fixed my issue. Thanks, all!
You need to log in
before you can comment on or make changes to this bug.
Description
•