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)

ARM
Android
defect

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 31

People

(Reporter: marco, Assigned: marco)

Details

(Whiteboard: [WebRuntime])

Attachments

(1 file, 3 obsolete files)

Attached patch Patch (obsolete) — 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 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 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+
Attached patch Patch v2 (obsolete) — Splinter Review
Assignee: nobody → mcastelluccio
Attachment #778073 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #783340 - Flags: review?(wjohnston)
Attachment #783340 - Flags: review?(mark.finkle)
Attachment #783340 - Flags: review?(wjohnston) → review+
Attachment #783340 - Flags: review?(mark.finkle) → review+
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
Marco: can you rebase the patch to apply to the current tip?
OS: Linux → Android
Hardware: x86_64 → ARM
Priority: -- → P2
Attached patch Patch v3 (obsolete) — Splinter Review
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)
Whiteboard: [WebRuntime]
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+
Attached patch PatchSplinter Review
Attachment #8390106 - Attachment is obsolete: true
Attachment #8395237 - Flags: review+
Keywords: checkin-needed
Keywords: checkin-needed
Whiteboard: [WebRuntime] → [WebRuntime][fixed-in-fx-team]
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [WebRuntime][fixed-in-fx-team] → [WebRuntime]
Target Milestone: --- → Firefox 31
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: