Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

detect and react to user-specified host permissions #184

Open
balmas opened this issue Dec 13, 2018 · 0 comments
Open

detect and react to user-specified host permissions #184

balmas opened this issue Dec 13, 2018 · 0 comments

Comments

@balmas
Copy link
Member

balmas commented Dec 13, 2018

There are three possible settings of user controls for host permissions: "On all sites" (this is a default now and this is the one we've tested our extension with), "On a specific site" (on sites that do not have any explicit permissions it requires user to click on either an icon or a menu to allow access for a site), "When you click the extension" (as previous, but requires user to click for all sites).
If extensions requires a click to be activated on a page, its icon is shown in a grayed circle:
image

This is pretty much OK for for all workflows because a majority of them require user to interact with the icon or the menu and that will unblock the extension. There is one exception, though. It is a page reload scenario, where we move to the other page and try to restore a state from a previous page. In this case permissions won't allow state reactivation unless user clicks on the icon. Right now it is a little messed up because background thinks extension is in an active state and changes its state object correspondingly. The extension is, however, deactivated, so clicking on an icon brings extension to a deactivated state instead of activating it. Clicking on the icon again do the activation, but the whole thing does not feel quite right.

In order to handle this we need to check permissions before trying to restore state on a new page. There could be different ways to do that. Unfortunately, that would involve changes of a control flow and more conditional logic. Don't know how critical it is, but ideally it would be preferable to combine this change with some other changes in webextension to avoid a lengthy testing cycle. Decision probably depends on how many people would start to use this feature and how important the state reloading on an inter page navigation is for those who enabled permission controls.

Checking other requirement updates now ...

Originally posted by @kirlat in #179 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant