I know that in the case when some extension is updated and requires additional permissions compared to a previously installed version, a dialog with the permission warnings will be shown.
My question is: is any dialog is going to be shown if some permissions are removed compared to the previous extension version?
is any dialog is going to be shown if some permissions is cutted off comparing with the previous extension version?
If your permissions decrease, no dialog will be shown.
Interesting fact: Chrome will still consider those permissions granted on installs that had the broad-permissions version before.
So if your next version reintroduces the same permission, only users that had the restricted-permission version as their first installed version will be notified. Makes it easier (but still not completely trivial) to recover from accidental permission deletion.
From the source code (thanks to Sungguk Lim for the link):
// Extensions can also silently upgrade to less permissions, and then
// silently upgrade to a version that adds these permissions back.
// The extension could then release a new version that
// removes the "omnibox" permission. When the user upgrades, Chrome will
// still remember that "omnibox" had been granted, so that if the
// extension once again includes "omnibox" in an upgrade, the extension
// can upgrade without requiring this user's approval.
Extension will be disabled when permissions increase, and dialog will be shown
See actual chromium code:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/extensions/extension_service.cc&sq=package:chromium&type=cs&l=1582&rcl=1453955600
According to the answers here if I hypothetically follow this path of publications in chrome store:
step 1) Publish extension example_v1 / permissions x
step 2) Update extension to example_v2 / permissions x+y (increasing permissions)
step 3) Update extension to example_v3 / permissions x (decreasing permissions to the initial state (v1))
The final state of the extension should be enabled once the permissions at the end will be the same as at the beginning, isn't it?
Could be possible that once chrome mark your extension as disabled (step 2) it doesn't mark it as enabled again by itself, but the user should do it instead?
Related
I've published a Chrome extension that has some default keyboard shortcuts specified in the manifest.json file. I've changed my mind about what the defaults should be, and would like to change them for new installs going forward.
But what happens to those users who've already installed it?
If the user hasn't changed the defaults, will the new version of the extension change the shortcuts to the new defaults, thereby confusing the user? (I'm hoping not.)
If the user has changed the defaults to something else, will the new version change them back? (I'm assuming not.)
I could test this out by publishing a toy extension and then pushing an update, but I'm hoping someone out there may have already done the experiment.
I built a chrome extension, available in the Chrome Web Store, that has an options/settings page. In the settings, people can add additional webpages to a blacklist (the blacklist is already populated with some websites when the extension is initially installed).
I am now about to release a v2 to the chrome extension (mostly css improvements and an additional feature) and wanted to know, if people have added a bunch of new webpages to their blacklist via settings when using v1, will pushing an update to google cause their settings to be reset (e.g., back to the original blacklist)? The blacklist is held in localStorage.
Thanks
No, it will not reset your settings after an update, localStorage and chrome.storage will be kept.
Btw, you can test updating process by building a crx file. There are plenty of tools which can help you to make build; (oncletom/crx is the good one).
I have created a playground application. I see that it creates shortcut files in my google drive. I tried to share it with incognito (because I want the doc to be available to anybody and do not know how to create another google account, so I log out into incognito). The shared link looks like https://drive.google.com/open?id=0B00--A0eRH1JLTdsX2t0LWw5RE0. But, incognito fails to view it. It says that "No preview avaialable" in what is supposed to be its google drive window and offers the log in
The key problem that I see is that playground application has the following structure, which comes from the official demo
function onAuthorized() {
function onFileLoaded(doc) {display(doc)}
gapi.drive.realtime.load(your_doc_id, onFileLoaded)
}
// App entry point -- start by authorization
gapi.auth.authorize({
client_id: rtClientId, scope: ['install', 'file'],
//user_id: userId,
immediate: !popup }, onAuthorized
);
which seems to demand authentication in the first place before displaying any doc. Authorization is problematic for the unsigned mode that I want my app to be available. I want to share a file and make it viewable to the general public, without the need to log in. This raises a question if incognito users are able to view or event edit my document. I also concern how to copy the doc to their account if desired: one thing is when you have created a file on your drive with my app, you can probably list the files and use drive.copy api to copy desired one and other thing when you want to copy a file that is not available on your google drive and the only thing you have is its id.
BTW, can you tell me which account to use for non-incognito testing from another account? If I create the document in one account I want to see how it looks/accessible from the another.
The Realtime API does not provide anonymous access by default. See https://developers.google.com/google-apps/realtime/faq#does_the_realtime_api_support_anonymous_access
"BTW, can you tell me which account to use for non-incognito testing from another account? If I create the document in one account I want to see how it looks/accessible from the another."
Use Chrome for one account. Use Firefox and other browsers for succeeding accounts.
Additional note:
Just so you have a clear understanding what Incognito is all about. What it can and cannot do so you don't mix things up.
How incognito mode works
What you view
Incognito is a mode that opens a new window where you can browse the
Internet in private without Chrome saving the sites you visit. You can
switch between an incognito window and any regular Chrome browsing
windows you have open. You'll only be in incognito mode when you're
using the incognito window.
Be careful. Incognito mode only prevents Chrome from saving your site
visit activity. It won't stop other sources from seeing your browsing
activity, including:
Your internet service provider Your employer (if you're using a work
computer) The websites you visit themselves What you've downloaded
Chrome won’t save a record of the files you download in incognito
mode. However, the downloaded files will be saved to your computer’s
Downloads folder, where you and any other users of your computer can
see and open them, even after you close your incognito tabs.
The default behavior for chrome.downloads.download is to download to the default download folder. It doesn't remember it if you change the folder. Can we save the download-to location for the next call-out?
References: https://developer.chrome.com/extensions/downloads
It's concerning that Chrome actually doesn't provide the ability for an extension to get the last download path. Some say, it's due to security concern and others say, there is no significant need to have the API available to users.
You also cannot store the download path in your extension because Chrome doesn't let you get the selected download folder. I hope Google provides us with the either of these features later.
This is not a supported feature, according to this Chromium discussion.
Summary:
If you specify a filename, it's never possible to save outside of ~/Downloads (this is a bummer, for me)
You should be able to manually implement something (in a subfolder only) using the id returned from Chrome.downloads.download
A few quotes I like (edited for brevity and politeness):
Would like a download option to choose recent download folder. Would be good to remember last download location per website, like you other settings.
Seems reasonable.
Chrome does remember the last chosen directory if no filename is specified to downloads.download with Save As... Given how Save As works without specifying a filename, my intuition would be it would work the same with a filename... but it doesn't.
That one is interesting. So it kind of supports it already. There's no security concern with saving outside of Downloads.
I have just been able to restore the "remember last download location" functionality, which used to work on my previous machine, in a new install by disabling extensions and Chrome apps provided by Google. This is what I have turned off:
Extension: Google Docs Offline
Chrome Apps: Docs, Sheets, Slides
I haven't tried to narrow down which of these have been the culprit, or if any other extensions (I have a bunch) have played a role. So YMMV. Good luck :)
SOLVED. Very simple way: Insert a USB-drive or SD-card. Go to chrome settings, and specify this drive as the default download location.
Remove the drive/SD-card. Download something - the first time you do it, Chrome will offer to save to your user document folder, but instead, you save it to whereever you want.
This location will be remembered next time. Voila. So easy.
In fact, you can save previous the download location.
If you do a clean install, first of everything, change the download settings to "ask every time". It is very important not to click the text box where you can specify one download location (if you click there just once, you need a clean install again).
Chrome will then bring up the download window with your last save location.
Furthermore, you should uncheck the "settings" in the sync preferences because it will break every time you sync your settings to a new browser.
At some point in the last couple of days a bug seems to have materialised in my app's Google Drive integration, despite me not having changed anything, and usage remaining fairly constant.
When you left click one of the app's documents in Drive a new about:blank tab opens showing the app's icon and the text "Sorry, an error occurred while opening this file. Please try again. [XXXXX]" where [XXXXX] is a short string that seems to be different every time. The create new works fine, and if you use the right-click menu and open with it also works fine.
All of this makes me think that there is a bug in the latest javascript update to Google Drive's main interface.
In terms of debugging, in the apiconsole the app has...
The initiate oauth2 option unchecked
The allow multiple files option unchecked
Mobile browser support checked
24 mime-types, 61 primary extensions, and 1 secondary extension registered
If it is a bug as Claudio has mentioned, I believe Google Drive SDK documentation needs to be updated too, since 'open' action is described only for "Open With" option:
https://developers.google.com/drive/integrate-open
I'm wondering how to trigger the proper action when registred mime-type can be managed by more than one installed application? Is there a way to set the default open action - or the application which created it will be used as the default? What's happen if you reach the application web by typing the url (not from UI Drive UI create action) and save the content on Drive, since you may be already authorized to do it?