chrome.permissions no longer available in content scripts?

613 views
Skip to first unread message

Steve Sobel

unread,
Feb 27, 2014, 2:28:20 AM2/27/14
to chromium-apps
My addon can no longer request optional permissions because the chrome.permissions object doesn't exist in the foreground.

If I inspect my background page, it exists, but the dialog of course doesn't pop up (because where would it?) so that's not of any use.

Is this a bug, or has there been a change to the behavior?  I can't seem to find anything useful on the documentation page about this...


Thanks,
Steve

Steve Sobel

unread,
Feb 27, 2014, 1:49:17 PM2/27/14
to chromi...@chromium.org
Replying to myself because others may find it useful and I think this merits some discussion due to either a regression or a bug:

chrome.permissions indeed is no longer available in content scripts and must now be accessed elsewhere.  Furthermore, the user doesn't seem to be presented with an "allow/deny" dialog anymore, either.  

As much as I am annoyed at how strict (and often misleadingly scary) Chrome's wording is about permissions - I do care about user's security and I feel this new behavior is a regression.

Here's how it works now:

When you call chrome.permissions.request - it must invoked by a user action (this is good), but not from a content script - so it's gotta be a button in the browser chrome (e.g. a toolbar button or an address bar button)....  It's frustrating that this is the case because I only want to request permissions to access certain site APIs when a user does something on a webpage that requires it - now I have to pop up a message in the webpage and direct them to a button up in their browser chrome somewhere...

Furthermore, and here's what I feel is a regression: the user isn't asked what the permission is or presented "allow" or "deny" buttons anymore. You click the button, you get the permission, period.  You aren't asked what that permission is!  This is far more likely to allow deceptive practices and insecure situations than allowing the previous allow/deny dialog from content scripts, and I really can't understand the logic at all unless this is unintentional / a bug.

I'm keenly interested to hear a take on this from someone at Google, because I think this is actually less safe/secure behavior on top of being a much more convoluted and difficult process for me to manage as a developer.

Steve

Scott Fujan

unread,
Feb 27, 2014, 1:58:54 PM2/27/14
to Steve Sobel, Chromium Apps
You have a couple things wrong. See: https://groups.google.com/a/chromium.org/forum/#!msg/chromium-extensions/-HYj8CysuGU/kRNKZ0OSBscJ

1) You can initiate a permission request from a content script, but it has to be passed to the background page to actually call it. The "user interaction" status is transferred to the background page code.

2) The "allow/deny" dialog is still shown, but after permission has been given once it stops showing (even if you remove the permissions). To get it to come back you must uninstall/reinstall the extension.


--
You received this message because you are subscribed to the Google Groups "Chromium Apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-app...@chromium.org.
To post to this group, send email to chromi...@chromium.org.
Visit this group at http://groups.google.com/a/chromium.org/group/chromium-apps/.
For more options, visit https://groups.google.com/a/chromium.org/groups/opt_out.

Steve Sobel

unread,
Feb 27, 2014, 2:02:46 PM2/27/14
to Scott Fujan, Chromium Apps
on #1 - so you call chrome.permissions.request() from the background page now?  I couldn't get this to work, but admittedly it was quite late at night and I was tired/frustrated by the lack of documentation / clarity on the change so I'll give it another shot.

on #2, I'm experiencing a bug, then.  I have working code right now that never shows an allow/deny dialog when you click the address bar button I'm using. The permission is just granted on click.  I'm using chrome.permission.remove() to remove it, because uninstalling the extension trashes all my preferences/data and is not something I'm willing to do to test.  

Assuming the lack of an uninstall/reinstall is the difference: If the permission has been removed, it should NOT be able to be re-added without an allow/deny dialog.

Steve

Scott Fujan

unread,
Feb 27, 2014, 2:08:41 PM2/27/14
to Steve Sobel, Chromium Apps
inline

On Thu, Feb 27, 2014 at 1:02 PM, Steve Sobel <st...@openingbands.com> wrote:
on #1 - so you call chrome.permissions.request() from the background page now?  I couldn't get this to work, but admittedly it was quite late at night and I was tired/frustrated by the lack of documentation / clarity on the change so I'll give it another shot.

You can call it from the background page, but it still has to be initiated by a user interaction -- so testing with the console doesn't work.


on #2, I'm experiencing a bug, then.  I have working code right now that never shows an allow/deny dialog when you click the address bar button I'm using. The permission is just granted on click.  I'm using chrome.permission.remove() to remove it, because uninstalling the extension trashes all my preferences/data and is not something I'm willing to do to test.  

I'm not saying that I agree with the policy, but it is specifically documented: "You should remove permissions when you no longer need them. After a permission has been removed, calling permissions.request() usually adds the permission back without prompting the user."

Steve Sobel

unread,
Feb 27, 2014, 2:15:04 PM2/27/14
to Scott Fujan, Chromium Apps
I am puzzled as to why permissions can not be removed using the console, but I'll make a debug button triggered by UI that removes them and give that a shot.  I can certainly understand why granting requires user interaction, but given the absence of an extension "permissions debug" panel, having to create a UI just to remove permissions is kind of silly.  That being said, I appreciate your response.

I definitely don't agree with the policy as documented. The argument that removing permissions that are no longer needed directly conflicts with the notion that they can be brought back without an allow/deny dialog. Why even bother removing them, then?

Steve
Reply all
Reply to author
Forward
0 new messages