Remove the permission manager workaround for Gaia

RESOLVED FIXED in Firefox 18

Status

()

defect
P1
normal
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: mounir, Assigned: mounir)

Tracking

Trunk
mozilla19
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed)

Details

(Whiteboard: [LOE:S] [qa-])

Attachments

(1 attachment)

This bug is about reverting bug 785631 so bug 777072 is fully working.

The idea, as explained in bug 785631 is to allow users/developers to update their profile between the landing of bug 785631 and this one.
Seems important for Basecamp so +ing.
blocking-basecamp: ? → +
Whiteboard: [LOE:S]
Whiteboard: [LOE:S] → [LOE:S] [WebAPI:P0]
I think we should have this being WebAPI:P1 because that means any app will have access to permissions from the default app (appId=0). This seems scary unless we are 100% sure that the default app has no permissions at all.
(In reply to Mounir Lamouri (:mounir) from comment #2)
> I think we should have this being WebAPI:P1 because that means any app will
> have access to permissions from the default app (appId=0). This seems scary
> unless we are 100% sure that the default app has no permissions at all.

Done.
Whiteboard: [LOE:S] [WebAPI:P0] → [LOE:S][WebAPI:P1]
Given that this is a bug and not a feature, I will work on that after feature freeze.
Whiteboard: [LOE:S][WebAPI:P1] → [LOE:S][WebAPI:P1][after feature freeze]
I have sent a Gaia pull request to use a newer xulrunner build so the correct permission info will be generated:
https://github.com/mozilla-b2g/gaia/pull/5137
I'm working on this earlier than expected because it seems like Etienne was running into bugs with permissions and that might likely be related (given that Gaia had no real per-app permissions). With this patch and the PR, things should be normal.
Whiteboard: [LOE:S][WebAPI:P1][after feature freeze] → [LOE:S][WebAPI:P1]
Posted patch PatchSplinter Review
Attachment #664461 - Flags: review?(justin.lebar+bug)
FWIW, Gaia pull request has landed, this can safely land now (as long as developers update the gaia repo).
Also, email sent to dev-gaia so they will have their xulrunners updated before this patch lands.
Whiteboard: [LOE:S][WebAPI:P1] → [LOE:S][WebAPI:P1][needs review]
Comment on attachment 664461 [details] [diff] [review]
Patch

r=incredibly-me.
Attachment #664461 - Flags: review?(justin.lebar+bug) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/7de3b05cd7d8
Flags: in-testsuite-
Whiteboard: [LOE:S][WebAPI:P1][needs review] → [LOE:S][WebAPI:P1]
Target Milestone: --- → mozilla18
(In reply to Mounir Lamouri (:mounir) from comment #8)
> FWIW, Gaia pull request has landed, this can safely land now (as long as
> developers update the gaia repo).

(In reply to Mounir Lamouri (:mounir) from comment #9)
> Also, email sent to dev-gaia so they will have their xulrunners updated
> before this patch lands.

That was not even 1% of the work needed here.  Your pull request even broke gaia, before this patch landed.

This patch is going to have to come out again.  This time though, we know what's needed to fix it up, since we took the time to test it while inbound was closed.

I don't know how many times I need to say this, but while we're all twiddling our fingers waiting on testing on infra, just ASK ME to test locally, instead of breaking a product days before feature freeze.
I think we should be able to reland this tomorrow.
Assignee: mounir → jones.chris.g
Target Milestone: mozilla18 → ---
I won't take credit for all the work you've done.
Assignee: jones.chris.g → mounir
Whiteboard: [LOE:S][WebAPI:P1] → [LOE:S][WebAPI:P1][needs some fixes somewhere to happen]
I had a workaround for preinstalled apps in gaia, but it epically breaks "eng" builds.  So need to do this right.
Depends on: 790849
Whiteboard: [LOE:S][WebAPI:P1][needs some fixes somewhere to happen] → [LOE:S][WebAPI:P1]
Whiteboard: [LOE:S][WebAPI:P1] → [LOE:S][WebAPI:P1][needs dependency list to be cleared]
Fabrice, how do you feel about adding a build/permissions.js hack to work around the pre-installed DB problem, temporarily?
Which kind of hack are you thinking about? I have a patch almost ready in bug 787439 to populate the permission db at startup, but I only tested with VARIANT=user builds for now.
Ah, great news!  (You don't want to know what hack I had in mind ;) .)
Whiteboard: [LOE:S][WebAPI:P1][needs dependency list to be cleared] → [LOE:S][WebAPI:P1][has reviewed patch][needs dependency list to be cleared]
Priority: -- → P1
Whiteboard: [LOE:S][WebAPI:P1][has reviewed patch][needs dependency list to be cleared] → [LOE:S][has reviewed patch][needs dependency list to be cleared]
I got a green light from Fabrice yesterday.

Re-landed:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a7be3bc10c58
https://hg.mozilla.org/mozilla-central/rev/a7be3bc10c58
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
https://hg.mozilla.org/releases/mozilla-aurora/rev/e9d90b26e252
Whiteboard: [LOE:S][has reviewed patch][needs dependency list to be cleared] → [LOE:S]
Depends on: 804420
Whiteboard: [LOE:S] → [LOE:S] [qa-]
You need to log in before you can comment on or make changes to this bug.