1368700 - Not able to specify when to enforce chrome_url_overrides and chrome_settings_overrides after installation of WebExtension addon

Status: UNCONFIRMED

(WebExtensions :: General, defect, P5)

Description

[tom.mai78101]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.3; rv:11.0) like Gecko

Steps to reproduce:

I have tried to look into methods of enforcing "chrome_url_overrides" and "chrome_settings_overrides" only after the user has accepted with permission that our add-on is allowed to enforce overrides.

Currently, both the "chrome_url_overrides" and "chrome_settings_overrides" are enforced upon installation of the add-on, and cancelled only when said add-on is removed. It cannot be somewhere in between, and add-on developers cannot choose when to enforce the overrides after the user has accepted and granted permissions for the add-ons to do so.



Actual results:

The only current accepted method is to have the user install 2 separate add-ons. One add-on does the core job, and the other add-on sets the new tab URL and homepage via "chrome_url_overrides" and "chrome_settings_overrides" in the manifest.json. 


Expected results:

There should be a method to let the add-on choose when to start enforcing the "chrome_url_overrides" and "chrome_settings_overrides", after the user has installed the add-on, and has given permission to allow us to enforce the overrides. Once enforced, the users should be allowed to disable the overrides at any time.

It cannot be allowed where the users has to install 2 or more WebExtension add-ons just for developers who want to separate custom add-on features from being forced to also include URL and settings overrides.

Comment 1

[Bob Silverberg [:bsilverberg]]

I was discussing this with the reporter in IRC. I think it may make sense to decouple this request from chrome_url_overrides and chrome_settings_overrides and make it more about extensions being able to set and clear these dynamically. One approach could be using BrowserSetting as documented at [1], which is currently used by the Privacy API [2]. This would allow an extension to set the value and clear the value (releasing control over the setting) via an API call.

tom.mai78101, does that sound like it would address the requirement you are describing here?

[1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/types/BrowserSetting
[2] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/privacy

Comment 2

[tom.mai78101]

(In reply to Bob Silverberg [:bsilverberg] from comment #1)
> tom.mai78101, does that sound like it would address the requirement you are
> describing here?
> 
> [1]
> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/types/
> BrowserSetting
> [2] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/privacy

Yes, it would theoretically. It needs to have some way of communicating to the browser that the add-on wishes to start enforcing the overrides.

Note that all restrictions of the overrides should stay the same, if not, can be a bit more stricter (if one wishes to do so...). The only minor change is the ability for the add-on to specify when to toggle to enforce the overrides or not.

Comment 3

[Bob Silverberg [:bsilverberg]]

I may be missing something that is special about the overrides, but I was thinking that if we introduced this new dynamic way of setting the pages it would be used in place of the manifest overrides, not that it would be used to control when the overrides in the manifest are applied.

Do you see an issue with that?

Comment 4

[tom.mai78101]

I do not see any issues thus far.

Comment 5

[Bob Silverberg [:bsilverberg]]

Andy, I'm pretty sure there were some discussions about this, and the decision was that we will never allow home page or new tab page to be overriden by extensions except via a manifest key. Does that sound accurate?

Comment 6

[Caitlin Neiman [:caitmuenster]]

Hi Tom, this has been added to the agenda for the July 11 WebExtension APIs Triage meeting. Would you be able to join us? 

Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting

Agenda: https://docs.google.com/document/d/1MEMC7EyZ2VVInbWod7FD2SFGp36osoxQkhUm5f0aNSs/edit#

Comment 7

[Andy McKay]

Just some comments from the meeting:

* We'll need to flesh out the API here and figure through all the scenarios, perhaps for the first iteration we'll have to keep it pretty simple.
* There was broad approval of the idea of using optional permissions for this in the sense that the add-on asks for permission to set the home page or new tab and if granted changes the page. When the permission is removed it would be reverted.
* It was suggested that you wouldn't be able to set it dynamically, just setting it to a static value defined in the manifest would work.

Comment 9

[Firefox Bug Husbandry Bot]

Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958