1<h2 id="manifest">Manifest</h2> 2<p>You must declare the "contentSettings" permission 3in your extension's manifest to use the API. 4For example:</p> 5<pre data-filename="manifest.json"> 6{ 7 "name": "My extension", 8 ... 9 <b>"permissions": [ 10 "contentSettings" 11 ]</b>, 12 ... 13} 14</pre> 15 16 17<h2 id="patterns">Content setting patterns</h2> 18<p> 19You can use patterns to specify the websites that each content setting affects. 20For example, <code>http://*.youtube.com/*</code> specifies youtube.com and all 21of its subdomains. The syntax for content setting patterns is the same as for 22<a href="match_patterns.html">match patterns</a>, with a few differences: 23<ul><li>For <code>http</code>, 24<code>https</code>, and <code>ftp</code> URLs, the path must be a wildcard 25(<code>/*</code>). For <code>file</code> URLs, the path must be completely 26specified and <strong>must not</strong> contain wildcards.</li> 27<li>In contrast to match patterns, content setting patterns can specify a port 28number. If a port number is specified, the pattern only matches websites with 29that port. If no port number is specified, the pattern matches all ports. 30</li> 31</ul> 32</p> 33 34<h3 id="pattern-precedence">Pattern precedence</h3> 35<p> 36When more than one content setting rule applies for a given site, the rule with 37the more specific pattern takes precedence. 38</p> 39<p>For example, the following patterns are ordered by precedence:</p> 40<ol> 41<li><code>http://www.example.com/*</code></li> 42<li><code>http://*.example.com/*</code> (matching 43example.com and all subdomains)</li> 44<li><code><all_urls></code> (matching every URL)</li> 45</ol> 46<p> 47Three kinds of wildcards affect how specific a pattern is: 48</p> 49<ul> 50<li>Wildcards in the port (for example 51<code>http://www.example.com:*/*</code>)</li> 52<li>Wildcards in the scheme (for example 53<code>*://www.example.com:123/*</code>)</li> 54<li>Wildcards in the hostname (for example 55<code>http://*.example.com:123/*</code>)</li> 56</ul> 57<p> 58If a pattern is more specific than another pattern in one part but less specific 59in another part, the different parts are checked in the following order: 60hostname, scheme, port. For example, the following patterns are ordered by 61precedence:</p> 62<ol> 63<li><code>http://www.example.com:*/*</code><br> 64Specifies the hostname and scheme.</li> 65<li><code>*:/www.example.com:123/*</code><br> 66Not as high, because although it specifies the hostname, it doesn't specify 67the scheme.</li> 68<li><code>http://*.example.com:123/*</code><br> 69Lower because although it specifies the port and scheme, it has a wildcard 70in the hostname.</li> 71</ol> 72 73<h2 id="primary-secondary">Primary and secondary patterns</h2> 74<p> 75The URL taken into account when deciding which content setting to apply depends 76on the content type. For example, for 77$ref:contentSettings.notifications settings are 78based on the URL shown in the omnibox. This URL is called the "primary" URL.</p> 79<p> 80Some content types can take additional URLs into account. For example, 81whether a site is allowed to set a 82$ref:contentSettings.cookies is decided based on the URL 83of the HTTP request (which is the primary URL in this case) as well as the URL 84shown in the omnibox (which is called the "secondary" URL). 85</p> 86<p> 87If multiple rules have primary and secondary patterns, the rule with the more 88specific primary pattern takes precedence. If there multiple rules have the same 89primary pattern, the rule with the more specific secondary pattern takes 90precedence. For example, the following list of primary/secondary pattern pairs 91is ordered by precedence:</p> 92<table> 93<tr><th>Precedence</th><th>Primary pattern</th><th>Secondary pattern</th> 94<tr> 95 <td>1</td> 96 <td><code>http://www.moose.com/*</code>, </td> 97 <td><code>http://www.wombat.com/*</code></td> 98</tr><tr> 99 <td>2</td> 100 <td><code>http://www.moose.com/*</code>, </td> 101 <td><code><all_urls></code></td> 102</tr><tr> 103 <td>3</td> 104 <td><code><all_urls></code>, </td> 105 <td><code>http://www.wombat.com/*</code></td> 106</tr><tr> 107 <td>4</td> 108 <td><code><all_urls></code>, </td> 109 <td><code><all_urls></code></td> 110</tr> 111</table> 112 113<h2 id="resource-identifiers">Resource identifiers</h2> 114<p> 115Resource identifiers allow you to specify content settings for specific 116subtypes of a content type. Currently, the only content type that supports 117resource identifiers is $ref:contentSettings.plugins, 118where a resource identifier identifies a specific plug-in. When applying content 119settings, first the settings for the specific plug-in are checked. If there are 120no settings found for the specific plug-in, the general content settings for 121plug-ins are checked. 122</p> 123<p> 124For example, if a content setting rule has the resource identifier 125<code>adobe-flash-player</code> and the pattern <code><all_urls></code>, 126it takes precedence over a rule without a resource identifier and the pattern 127<code>http://www.example.com/*</code>, even if that pattern is more specific. 128</p> 129<p> 130You can get a list of resource identifiers for a content type by calling the 131$ref:contentSettings.ContentSetting.getResourceIdentifiers method. The returned list 132can change with the set of installed plug-ins on the user's machine, but Chrome 133tries to keep the identifiers stable across plug-in updates. 134</p> 135 136<h2 id="examples">Examples</h2> 137 138<p> 139You can find samples of this API on the 140<a href="samples.html#contentSettings">sample page</a>. 141</p> 142