Closed
Bug 895638
Opened 12 years ago
Closed 11 years ago
Reinstall permissions when the runtime is upgraded
Categories
(Firefox for Android Graveyard :: Web Apps (PWAs), defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
Firefox 31
People
(Reporter: marco, Assigned: marco)
Details
(Whiteboard: [WebRuntime])
Attachments
(1 file, 3 obsolete files)
|
1.61 KB,
patch
|
marco
:
review+
|
Details | Diff | Splinter Review |
I think we should reinstall permissions when the runtime is upgraded and just install them (not reinstall) on first run.
Also, on upgrades we should do the same things we do on first run, as the preferences could change.
Attachment #778073 -
Flags: feedback?(mark.finkle)
Comment 1•12 years ago
|
||
Comment on attachment 778073 [details] [diff] [review]
Patch
># HG changeset patch
># Parent 4e163cc4cbc912ec621511b767d47d8ae63229cd
># User Marco Castelluccio <mar.castelluccio@studenti.unina.it>
>Reinstall permissions when the runtime is upgraded (and not reinstall permissions, but just install, on first run)
>
>diff --git a/mobile/android/chrome/content/WebAppRT.js b/mobile/android/chrome/content/WebAppRT.js
>--- a/mobile/android/chrome/content/WebAppRT.js
>+++ b/mobile/android/chrome/content/WebAppRT.js
>@@ -33,31 +33,31 @@ let WebAppRT = {
> pref("media.useAudioChannelService", true)
> ],
>
> init: function(aStatus, aUrl, aCallback) {
> this.deck = document.getElementById("browsers");
> this.deck.addEventListener("click", this, false, true);
>
> // on first run, update any prefs
>- if (aStatus == "new") {
>+ if (aStatus == "new" || aStatus == "upgrade") {
> this.getDefaultPrefs().forEach(this.addPref);
>
>- // prevent offering to use helper apps for things that this app handles
>- // i.e. don't show the "Open in market?" popup when we're showing the market app
>- let uri = Services.io.newURI(aUrl, null, null);
>-
> // update the blocklist url to use a different app id
> let blocklist = Services.prefs.getCharPref("extensions.blocklist.url");
> blocklist = blocklist.replace(/%APP_ID%/g, "webapprt-mobile@mozilla.org");
> Services.prefs.setCharPref("extensions.blocklist.url", blocklist);
>
> this.getManifestFor(aUrl, function (aManifest, aApp) {
> if (aManifest) {
>- PermissionsInstaller.installPermissions(aApp, true);
>+ if (aStatus == "new") {
>+ PermissionsInstaller.installPermissions(aApp, false);
>+ } else if (aStatus == "upgrade") {
>+ PermissionsInstaller.installPermissions(aApp, true);
>+ }
> }
> });
> }
>
> this.findManifestUrlFor(aUrl, aCallback);
> },
>
> getManifestFor: function (aUrl, aCallback) {
Attachment #778073 -
Flags: feedback?(wjohnston)
Attachment #778073 -
Flags: feedback?(mark.finkle)
Attachment #778073 -
Flags: feedback+
Comment 2•12 years ago
|
||
Comment on attachment 778073 [details] [diff] [review]
Patch
Review of attachment 778073 [details] [diff] [review]:
-----------------------------------------------------------------
::: mobile/android/chrome/content/WebAppRT.js
@@ +42,1 @@
> this.getDefaultPrefs().forEach(this.addPref);
I don't think we really need to do this on upgrades. These prefs are unrelated to the app...
@@ +44,4 @@
> // update the blocklist url to use a different app id
> let blocklist = Services.prefs.getCharPref("extensions.blocklist.url");
> blocklist = blocklist.replace(/%APP_ID%/g, "webapprt-mobile@mozilla.org");
> Services.prefs.setCharPref("extensions.blocklist.url", blocklist);
Same for this probably. If the user has somehow figured out how to flip this, I don't really want to flip it back on them. The permissions are a bit different in that the app itself specifies them, and I think we need to respect its wishes.
Attachment #778073 -
Flags: feedback?(wjohnston) → feedback+
| Assignee | ||
Comment 3•12 years ago
|
||
Assignee: nobody → mcastelluccio
Attachment #778073 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #783340 -
Flags: review?(wjohnston)
Attachment #783340 -
Flags: review?(mark.finkle)
Updated•12 years ago
|
Attachment #783340 -
Flags: review?(wjohnston) → review+
Updated•12 years ago
|
Attachment #783340 -
Flags: review?(mark.finkle) → review+
| Assignee | ||
Comment 4•12 years ago
|
||
I completely forgot about this bug. I'll modify the patch because we're basically calling |PermissionsInstaller.installPermission| with the second parameter as true everywhere.
But we still need to reinstall permissions on update.
Summary: Reinstall permissions when the runtime is upgraded (and not reinstall permissions, but just install, on first run) → Reinstall permissions when the runtime is upgraded
Comment 5•12 years ago
|
||
Marco: can you rebase the patch to apply to the current tip?
OS: Linux → Android
Hardware: x86_64 → ARM
Updated•12 years ago
|
Priority: -- → P2
| Assignee | ||
Comment 6•12 years ago
|
||
I'm always passing |true| as the second argument to installPermissions because, even if |aStatus| is new, it could still be a reinstallation.
Attachment #783340 -
Attachment is obsolete: true
Attachment #8390106 -
Flags: review?(wjohnston)
Updated•11 years ago
|
Whiteboard: [WebRuntime]
Comment 7•11 years ago
|
||
Comment on attachment 8390106 [details] [diff] [review]
Patch v3
Review of attachment 8390106 [details] [diff] [review]:
-----------------------------------------------------------------
::: mobile/android/chrome/content/WebappRT.js
@@ +55,5 @@
> Services.prefs.setCharPref("extensions.blocklist.url", blocklist);
>
> + this.installPermissions(aUrl);
> + } else if (aStatus == "upgrade") {
> + this.installPermissions(aUrl);
Since this is repeated, can you move it out of the if-else block.
Attachment #8390106 -
Flags: review?(wjohnston) → review+
| Assignee | ||
Comment 8•11 years ago
|
||
Attachment #8390106 -
Attachment is obsolete: true
Attachment #8395237 -
Flags: review+
| Assignee | ||
Updated•11 years ago
|
Keywords: checkin-needed
Comment 9•11 years ago
|
||
Keywords: checkin-needed
Whiteboard: [WebRuntime] → [WebRuntime][fixed-in-fx-team]
Comment 10•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [WebRuntime][fixed-in-fx-team] → [WebRuntime]
Target Milestone: --- → Firefox 31
Updated•5 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•