Closed Bug 804420 Opened 12 years ago Closed 6 years ago

B2G SpecialPowers.addPermission fails if you pass in a url

Categories

(Testing :: Mochitest, defect)

x86
macOS
defect
Not set
normal

Tracking

(blocking-basecamp:-)

RESOLVED INVALID
blocking-basecamp -

People

(Reporter: onecyrenus, Unassigned)

References

Details

https://github.com/mozilla/mozilla-central/commit/361021f9dff22094a13c8be977f1bbfa881333f2

Based upon the above commit, if you use the specialPowersAPI and just pass in the url, this doesn't correctly add the permission to the app. 

https://github.com/mozilla/mozilla-central/blob/master/testing/specialpowers/content/specialpowersAPI.js#L1211

If you can't addPermissions to an app, then you can't run any tests. 

either need to install the App, or be able to fake have the app installed, and directly set the permissions for that specific app. 

Unsure which route we want to go.
blocking-basecamp: --- → ?
Component: Builds → Mochitest
Product: Boot2Gecko → Testing
Ok, it sounds like this is caused by bug 785632.

Maybe the test that was added in bug 777072 has a way of fixing this issue?
http://mxr.mozilla.org/mozilla-central/source/extensions/cookie/test/test_permissionmanager_app_isolation.html?force=1

Perhaps Mounir knows a solution?
Blocks: 785632
Sure. There are two solutions:
1. pass window.document from the app (best solution)
2. pass { url: <URL>, appId: <APPID>, isInBrowserElement: <INBROWSERELEMENT> } (less good solution)

See: https://github.com/mozilla/mozilla-central/blob/master/testing/specialpowers/content/specialpowersAPI.js#L1186
Mounir, 
   To this point, how will we know the AppId ? window.document isn't really a good solution.  

1) permissions are granted upon page load, not specifically when you try to access the api.  

2) an iframe on a different domain is used to pretend you are within app.

Normally I am setting permissions from the parent window, and then launching the iframe. This has been the only mechanism that worked for me, willing to change if you know a better way. 

Passing in a url is a great solution.  From the url the api should figure out the AppID, and append it to the permission request.  Or there could be an api to be able to infer the AppID. 

The bug is to note that the API exposes the ability to pass in a url, but no longer works.
(In reply to dclarke@mozilla.com  [:onecyrenus] from comment #3)
> Mounir, 
>    To this point, how will we know the AppId ? window.document isn't really
> a good solution.  

Why isn't window.document a good solution? Is that because the app is run OOP?

> 1) permissions are granted upon page load, not specifically when you try to
> access the api.  

I'm not sure how this is relevant.

> 2) an iframe on a different domain is used to pretend you are within app.

I guess the iframe has mozapp attribute set to a manifest, right?

> Normally I am setting permissions from the parent window, and then launching
> the iframe. This has been the only mechanism that worked for me, willing to
> change if you know a better way. 
> 
> Passing in a url is a great solution.  From the url the api should figure
> out the AppID, and append it to the permission request.  Or there could be
> an api to be able to infer the AppID. 

No. You can't infer an appId based on an URL, this is not a 1:1 relationship.

> The bug is to note that the API exposes the ability to pass in a url, but no
> longer works.

That's not a bug but a feature.

What you could do is using the app registry to get the appid for a given application manifest. From there, you will be able to set the permission to the app using the given appid, the url and you can likely set inBroswserElement to false in most cases.
(In reply to Mounir Lamouri (:mounir) from comment #4)
> (In reply to dclarke@mozilla.com  [:onecyrenus] from comment #3)
> > Mounir, 
> >    To this point, how will we know the AppId ? window.document isn't really
> > a good solution.  
> 
> Why isn't window.document a good solution? Is that because the app is run
> OOP?
> 
> > 1) permissions are granted upon page load, not specifically when you try to
> > access the api.  
> 
> I'm not sure how this is relevant.  

This is relevant because you have to reload the page, after permissions are granted in order to get the correct permissions on the page. 

> 
> > 2) an iframe on a different domain is used to pretend you are within app.
> 
> I guess the iframe has mozapp attribute set to a manifest, right?
> 
> > Normally I am setting permissions from the parent window, and then launching
> > the iframe. This has been the only mechanism that worked for me, willing to
> > change if you know a better way. 
> > 
> > Passing in a url is a great solution.  From the url the api should figure
> > out the AppID, and append it to the permission request.  Or there could be
> > an api to be able to infer the AppID. 
> 
> No. You can't infer an appId based on an URL, this is not a 1:1 relationship.
> 
> > The bug is to note that the API exposes the ability to pass in a url, but no
> > longer works.
> 
> That's not a bug but a feature.

A bug is a feature that doesn't work.  Setting an app_id of 0 doesn't work. 

> 
> What you could do is using the app registry to get the appid for a given
> application manifest. From there, you will be able to set the permission to
> the app using the given appid, the url and you can likely set
> inBroswserElement to false in most cases.

How would we do this piece ? Where is the app registry, as i feel this is what should occur in the specialpermissions api.
You have to use getAppLocalIdByManifestURL(<MANIFEST_URL>) from nsIAppsService (not the app registry, sorry). You just have to get the service with the CID being "@mozilla.org/AppsService;1".

Like that:
let gAppsService = Cc["@mozilla.org/AppsService;1"]
                     .getService(Ci.nsIAppsService);

let appId = gAppsService.getAppLocalIdByManifestURL(<MANIFEST_URL>);
What's the current status here?
Flags: needinfo?(dclarke)
We can get the information from the AppsService, but the out of spec implementation inside addPermission should be deprecated.
Flags: needinfo?(dclarke)
(In reply to dclarke@mozilla.com  [:onecyrenus] from comment #8)
> We can get the information from the AppsService, but the out of spec
> implementation inside addPermission should be deprecated.

Can you file a separate bug to do that deprecation?

Thanks for the update.
blocking-basecamp: ? → -
Mass resolving of B2G mochitest bugs.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.