You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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:
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)
The text was updated successfully, but these errors were encountered: