Closed
Bug 1110606
Opened 10 years ago
Closed 6 years ago
Need to grant mozApps.mgmt to home screens when installed via webIDE
Categories
(Core Graveyard :: DOM: Apps, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: kgrandon, Unassigned)
References
Details
Currently we only expose mozApps.mgmt to the home screen which is set as the current home screen. This unfortunately makes it so developers can not test privileged home screens in webIDE. For replaceable home screens to be usable, we need to expose this permission when installing a home screen over webIDE.
This is currently where we check that the app is the current home screen: http://hg.mozilla.org/mozilla-central/annotate/32b0ce626ec8/dom/apps/Webapps.js#l269
Reporter | ||
Comment 1•10 years ago
|
||
Fabrice, Ted - do you guys have any ideas about how to solve this?
Flags: needinfo?(tclancy)
Flags: needinfo?(fabrice)
Comment 2•10 years ago
|
||
(In reply to Kevin Grandon :kgrandon from comment #1)
> Fabrice, Ted - do you guys have any ideas about how to solve this?
This is bound to the homescreen.manifestURL setting to match the new homescreen manifest url. That should happen by switching to the new homescreen from the settings app iirc.
Flags: needinfo?(fabrice)
Reporter | ||
Comment 3•10 years ago
|
||
Right, but when we test a home screen with the webIDE, it does not set the app as the default home screen. If a user installs an app using webIDE, they should be brought to a working app.
Comment 4•10 years ago
|
||
If so, the webapps actor should check the app role and switch the setting. Adding that at https://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/webapps.js#278 should work:
if (aApp.role === "homescreen") {
let settings = Cc["@mozilla.org/settingsService;1"].getService("nsISettingsService");
settings.createLock().set("homescreen.manifestURL", aApp.manifestURL, null);
}
Reporter | ||
Comment 5•10 years ago
|
||
Switching the home screen of the developer phone doesn't seem like the right option to me either, but it might be a quick workaround. Seems to me we should probably either change the permission checking, or have some way of allowing it when being installed from a dev tool. Thanks for the info though, we could probably go with that initially.
Updated•10 years ago
|
Flags: needinfo?(tclancy)
Updated•7 years ago
|
Product: Core → Core Graveyard
Comment 6•6 years ago
|
||
Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•