Re: Core API Proposal

Hi Mike and co-signatories,

Thanks for getting the ball rolling. I've very happy to see multiple browser vendors backing this initiative, as that's a strong sign we will be making actual progress.

I think the approach you highlight is a good way to start. There are lots of things we may want to specify eventually, but starting with the core of what makes extensions work and making sure that that's well defined and strongly interoperable should provide a strong base to build upon later.

Things that don't get included in this first pass should not be considered as rejected ideas, just as things we will look into later.

So that the results of the discussion you're starting here get recorded in the right format, I've set up a github repo to with a stub specification (in the respec format) there, and made you an editor:

https://browserext.github.io/browserext/

Once we have something there, contributions via pull requests are encouraged, and key contributors can also be made into co-editors if desired.

I'd like to encourage everyone who plans to participate in (re-)reading the charter, since it outlines the way this CG is supposed to work. 

https://browserext.github.io/charter/

TL;DR:
 * high level discussions on this mailing list
 * detailed discussions via github issues / pull requests
 * Decisions under consensus model, not BDFL model
 * Editors can make changes to the document without
   explicit group decisions, as long as they keep
   the group informed of what they do, and follow the
   group's decision when there is one
 * We may occasionally hold teleconfs or face 2 face meetings.
   Minutes of such meetings will be posted to this list,
   and decisions taken during such meeting are provisional for 10 days

Speaking of meetings, while I don't expect to this group to have meetings regularly
in the long run, I think it could be useful to have a handful of teleconfs at first to get things started. This is open to any member of this CG.

Based on where the co-signatories (and I) are located, I suggest the following for the kick-off meeting:

Thu May 5 @ 1:30-2:30 am UTC
  Wed May 4 @ 6:30-7:30pm (US Pacific) 
  Thu May 5 @ 7-8am (Chandigarh India)
  Thu May 5 @ 10:30-11:30am (Japan)

I realize this is a lousy time for anyone based in Europe, but finding a time slot that works in more than 3 time zones is always going to be a challenge, and I want to make sure that at least the browser vendors co-signing Mike's mail can participate.

If that sounds reasonable, I'll send an reminder/agenda to this list, and details for joining the call to the private list (https://lists.w3.org/Archives/Member/internal-browserext/)

Best regards,
Florian Rivoal
Co-chair

> On May 3, 2016, at 07:00, Mike Pietraszak <mikepie@microsoft.com> wrote:
> 
> Because browsers supported different add-on models, extension authors wound up creating divergent codebases and delivering different browser-specific add-ons. This Community Group's goal is to make browser extension code much more interoperable across browsers by specifying common extension interfaces and well-defined browser behavior. This will allow extension authors to greatly reduce or eliminate the rework necessary to create extensions that target different browsers. 
>  
> Here's a possible roadmap for this work:
> 1. Identify the core objects and manifest keys
> 2. Define interop behavior and specific APIs (functions, events and associated types)
> 3. Clarify CSP security, browser-specific API syntax and packaging
> 4. Iterate
>  
> We would like to suggest our Community Group start by 1) identifying a set of core interoperable objects and associated manifest keys. We think this core should provide the necessary functionality that extension authors will need for: page modification, browser UI augmentation and network request modification. Below is a proposed set of core objects that we think meets this criteria.
>  
> Next, our Community Group can 2) document and discuss the browser behavior (to ensure interoperability) and specific functions/events for each object (e.g. browserAction.setIcon(), pageAction.onClicked(), tabs.sendMessage(), etc.). Then we can move on to specify 3) the security model, the method for browsers to provide unique API that aren't in the standard and the packaging format.
>  
> For all stages, we can use GitHub to store the documents and update them. Florian has offered to grant write permission to Community Group members to allow drafts to be submitted.
>  
> What do other members think? Is this the right approach? Regarding the objects below, what is missing? Or unnecessary?
>  
> Sincerely,
> Mike Pietraszak & John Hazen, Microsoft
> Kris Maglione & Andy McKay, Mozilla
> Shwetank Dixit & Bruce Lawson, Opera
>  
> Proposed core APIs:
>   browserAction
>   contextMenu
>   extension
>   i18n
>   pageAction
>   runtime
>   tabs
>   webNavigation
>   webRequest
>   windows
>  
> Proposed manifest format:
> // Before parsing the manifest, standards-compliant browsers are expected to pre-scan
> // and remove "//" comments. After this step the manifest.json file format for browser
> // extensions is expected to be fully JSON compliant. Malformed JSON files are not supported.
> //
> // Other manifest keys that are well-formed JSON but are not listed here must be ignored.
> //
> // Note that some fields marked as Optional here are required by vendor-specific distribution Stores.
>  
> {
>   "name": "The Name of Your Extension",             // Required
>   "version": "Your Extension Verison",              // Required
>   "default_locale": "en",                           // Required if locales are used. Otherwise, not allowed
>  
>   "description": "Description for Your Extensions",  
>   "icons": {...},                                   
>   "developer": {                                    
>        "name": "Your Name or Company",             
>        "url": "Company Website"                     
>   }
>  
>   // Note: Some browsers may support either browser_action or page_action, but not both
>   "browser_action": {  
>       "default_icon": {...},                        // Same format as "icons"
>       "default_popup": "Page URL",
>       "default_title": "Title string"
>   },
>   "page_action": {...},                             // Same format as "browser_action"
>   
>   "browser_specific_settings": {                   
>        "<browser_name>": {                          // Examples "gecko","opera","edge"
>             "<key>": "<value>"                      // Examples "strict_min_version": "42.0", "id": "addon@example.com"
>        }
>   },
>  
>   "background": {                                  
>       "page": "Page URL",                           // Only one of "page" or "scripts" may be specified, but not both
>       "scripts": [],                                // Only one of "page" or "scripts" may be specified, but not both
>       "persistent": false                           // Required if "background" is specified
>   },
>  
>   "content_scripts": {                                                   
>       "all_frames": false,                         
>       "css": [],                                  
>       "exclude_matches": [],                       
>       "js": [],                                    
>       "matches": [],                               
>       "run_at" : "document_start"                   // Also "document_end", "document_idle"
>   }
>  
>   "content_security_policy": "<policy-string>",    
>   
>   "manifest_version": 2,                            // Not used
>  
>   "required_keys": [],                              // If a browser does not recognize a key in the list, it must
>                                                     // reject the manifest (e.g. "sidebar_action")
>                                                     // Future keys may be required to be in the list if used.
>  
>   "permissions": {                                 
>        "activeTab",                                               
>        "contextMenus",                             
>        "storage",                                  
>        "tabs",                                      
>        "webNavigation",                           
>        "webRequest",                               
>        "webRequestBlocking",                       
>        "<url-pattern>"                              // Examples "http://*/*", ""
>   },
>  
>   "web_accessible_resources": [...]                
> }

Received on Tuesday, 3 May 2016 08:16:51 UTC