Bug 1322235: Part 1 - Add native MatchPattern and MatchGlob bindings. r=billm,aswan
Bill, can you please review the binding code, and the general sanity of the
platform code. Andrew and zombie, can you please matching algorithms and
tests.
Change summary:
The existing JavaScript matching code works well overall, but it needs to be
called a lot, particularly from hot code paths. In most cases, the overhead of
the matching code on its own adds up enough to cause a problem. When we have
to call out to JavaScript via XPConnect to make a policy decision, it adds up
even more.
These classes solve both of these problems by a) being very fast, and b) being
accessible directly from C++. They are particularly optimized for the common
cases where only literal or prefix matches are required, and they take special
steps to avoid virtual calls wherever possible, and caching computed URL
values so that they can be reused across many match operations without
additional overhead.
MozReview-Commit-ID: BZzPZDQRnl
--HG--
rename : toolkit/modules/tests/xpcshell/test_MatchPattern.js => toolkit/components/extensions/test/xpcshell/test_MatchPattern.js
extra : rebase_source : c93c4c6c36460eb5ad0fc3aa86ad42a72e76bb6c
2017-05-24 21:57:29 +00:00
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
|
|
|
|
|
|
|
interface Cookie;
|
|
|
|
interface URI;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* A URL match pattern as used by the WebExtension and Chrome extension APIs.
|
|
|
|
*
|
|
|
|
* A match pattern is a string with one of the following formats:
|
|
|
|
*
|
|
|
|
* - "<all_urls>"
|
|
|
|
* The literal string "<all_urls>" matches any URL with a supported
|
|
|
|
* protocol.
|
|
|
|
*
|
|
|
|
* - <proto>://<host>/<path>
|
|
|
|
* A URL pattern with the following placeholders:
|
|
|
|
*
|
|
|
|
* - <proto>
|
|
|
|
* The protocol to match, or "*" to match either "http" or "https".
|
|
|
|
* - <host>
|
|
|
|
* The hostname to match. May be either a complete, literal hostname to
|
|
|
|
* match a specific host, the wildcard character "*", to match any host,
|
|
|
|
* or a subdomain pattern, with "*." followed by a domain name, to match
|
|
|
|
* that domain name or any subdomain thereof.
|
|
|
|
* - <path>
|
|
|
|
* A glob pattern for paths to match. A "*" may appear anywhere within
|
|
|
|
* the path, and will match any string of characters. If no "*" appears,
|
|
|
|
* the URL path must exactly match the pattern path.
|
|
|
|
*/
|
|
|
|
[Constructor(DOMString pattern, optional MatchPatternOptions options),
|
|
|
|
ChromeOnly, Exposed=(Window,System)]
|
|
|
|
interface MatchPattern {
|
|
|
|
/**
|
|
|
|
* Returns true if the given URI matches the pattern.
|
|
|
|
*
|
|
|
|
* If explicit is true, only explicit domain matches, without wildcards, are
|
|
|
|
* considered.
|
|
|
|
*/
|
2017-09-07 04:56:45 +00:00
|
|
|
[Throws]
|
Bug 1322235: Part 1 - Add native MatchPattern and MatchGlob bindings. r=billm,aswan
Bill, can you please review the binding code, and the general sanity of the
platform code. Andrew and zombie, can you please matching algorithms and
tests.
Change summary:
The existing JavaScript matching code works well overall, but it needs to be
called a lot, particularly from hot code paths. In most cases, the overhead of
the matching code on its own adds up enough to cause a problem. When we have
to call out to JavaScript via XPConnect to make a policy decision, it adds up
even more.
These classes solve both of these problems by a) being very fast, and b) being
accessible directly from C++. They are particularly optimized for the common
cases where only literal or prefix matches are required, and they take special
steps to avoid virtual calls wherever possible, and caching computed URL
values so that they can be reused across many match operations without
additional overhead.
MozReview-Commit-ID: BZzPZDQRnl
--HG--
rename : toolkit/modules/tests/xpcshell/test_MatchPattern.js => toolkit/components/extensions/test/xpcshell/test_MatchPattern.js
extra : rebase_source : c93c4c6c36460eb5ad0fc3aa86ad42a72e76bb6c
2017-05-24 21:57:29 +00:00
|
|
|
boolean matches(URI uri, optional boolean explicit = false);
|
|
|
|
|
2017-09-07 04:56:45 +00:00
|
|
|
[Throws]
|
|
|
|
boolean matches(DOMString url, optional boolean explicit = false);
|
|
|
|
|
Bug 1322235: Part 1 - Add native MatchPattern and MatchGlob bindings. r=billm,aswan
Bill, can you please review the binding code, and the general sanity of the
platform code. Andrew and zombie, can you please matching algorithms and
tests.
Change summary:
The existing JavaScript matching code works well overall, but it needs to be
called a lot, particularly from hot code paths. In most cases, the overhead of
the matching code on its own adds up enough to cause a problem. When we have
to call out to JavaScript via XPConnect to make a policy decision, it adds up
even more.
These classes solve both of these problems by a) being very fast, and b) being
accessible directly from C++. They are particularly optimized for the common
cases where only literal or prefix matches are required, and they take special
steps to avoid virtual calls wherever possible, and caching computed URL
values so that they can be reused across many match operations without
additional overhead.
MozReview-Commit-ID: BZzPZDQRnl
--HG--
rename : toolkit/modules/tests/xpcshell/test_MatchPattern.js => toolkit/components/extensions/test/xpcshell/test_MatchPattern.js
extra : rebase_source : c93c4c6c36460eb5ad0fc3aa86ad42a72e76bb6c
2017-05-24 21:57:29 +00:00
|
|
|
/**
|
|
|
|
* Returns true if a URL exists which a) would be able to access the given
|
|
|
|
* cookie, and b) would be matched by this match pattern.
|
|
|
|
*/
|
|
|
|
boolean matchesCookie(Cookie cookie);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns true if this pattern will match any host which would be matched
|
|
|
|
* by the given pattern.
|
|
|
|
*/
|
|
|
|
boolean subsumes(MatchPattern pattern);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns true if there is any host which would be matched by both this
|
|
|
|
* pattern and the given pattern.
|
|
|
|
*/
|
|
|
|
boolean overlaps(MatchPattern pattern);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* The match pattern string represented by this pattern.
|
|
|
|
*/
|
|
|
|
[Constant]
|
|
|
|
readonly attribute DOMString pattern;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* A set of MatchPattern objects, which implements the MatchPattern API and
|
|
|
|
* matches when any of its sub-patterns matches.
|
|
|
|
*/
|
|
|
|
[Constructor(sequence<(DOMString or MatchPattern)> patterns, optional MatchPatternOptions options),
|
|
|
|
ChromeOnly, Exposed=(Window,System)]
|
|
|
|
interface MatchPatternSet {
|
|
|
|
/**
|
|
|
|
* Returns true if the given URI matches any sub-pattern.
|
|
|
|
*
|
|
|
|
* If explicit is true, only explicit domain matches, without wildcards, are
|
|
|
|
* considered.
|
|
|
|
*/
|
2017-09-07 04:56:45 +00:00
|
|
|
[Throws]
|
Bug 1322235: Part 1 - Add native MatchPattern and MatchGlob bindings. r=billm,aswan
Bill, can you please review the binding code, and the general sanity of the
platform code. Andrew and zombie, can you please matching algorithms and
tests.
Change summary:
The existing JavaScript matching code works well overall, but it needs to be
called a lot, particularly from hot code paths. In most cases, the overhead of
the matching code on its own adds up enough to cause a problem. When we have
to call out to JavaScript via XPConnect to make a policy decision, it adds up
even more.
These classes solve both of these problems by a) being very fast, and b) being
accessible directly from C++. They are particularly optimized for the common
cases where only literal or prefix matches are required, and they take special
steps to avoid virtual calls wherever possible, and caching computed URL
values so that they can be reused across many match operations without
additional overhead.
MozReview-Commit-ID: BZzPZDQRnl
--HG--
rename : toolkit/modules/tests/xpcshell/test_MatchPattern.js => toolkit/components/extensions/test/xpcshell/test_MatchPattern.js
extra : rebase_source : c93c4c6c36460eb5ad0fc3aa86ad42a72e76bb6c
2017-05-24 21:57:29 +00:00
|
|
|
boolean matches(URI uri, optional boolean explicit = false);
|
|
|
|
|
2017-09-07 04:56:45 +00:00
|
|
|
[Throws]
|
|
|
|
boolean matches(DOMString url, optional boolean explicit = false);
|
|
|
|
|
Bug 1322235: Part 1 - Add native MatchPattern and MatchGlob bindings. r=billm,aswan
Bill, can you please review the binding code, and the general sanity of the
platform code. Andrew and zombie, can you please matching algorithms and
tests.
Change summary:
The existing JavaScript matching code works well overall, but it needs to be
called a lot, particularly from hot code paths. In most cases, the overhead of
the matching code on its own adds up enough to cause a problem. When we have
to call out to JavaScript via XPConnect to make a policy decision, it adds up
even more.
These classes solve both of these problems by a) being very fast, and b) being
accessible directly from C++. They are particularly optimized for the common
cases where only literal or prefix matches are required, and they take special
steps to avoid virtual calls wherever possible, and caching computed URL
values so that they can be reused across many match operations without
additional overhead.
MozReview-Commit-ID: BZzPZDQRnl
--HG--
rename : toolkit/modules/tests/xpcshell/test_MatchPattern.js => toolkit/components/extensions/test/xpcshell/test_MatchPattern.js
extra : rebase_source : c93c4c6c36460eb5ad0fc3aa86ad42a72e76bb6c
2017-05-24 21:57:29 +00:00
|
|
|
/**
|
|
|
|
* Returns true if any sub-pattern matches the given cookie.
|
|
|
|
*/
|
|
|
|
boolean matchesCookie(Cookie cookie);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns true if any sub-pattern subsumes the given pattern.
|
|
|
|
*/
|
|
|
|
boolean subsumes(MatchPattern pattern);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns true if any sub-pattern overlaps the given pattern.
|
|
|
|
*/
|
|
|
|
boolean overlaps(MatchPattern pattern);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns true if any sub-pattern overlaps any sub-pattern the given
|
|
|
|
* pattern set.
|
|
|
|
*/
|
|
|
|
boolean overlaps(MatchPatternSet patternSet);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns true if any sub-pattern overlaps *every* sub-pattern in the given
|
|
|
|
* pattern set.
|
|
|
|
*/
|
|
|
|
boolean overlapsAll(MatchPatternSet patternSet);
|
|
|
|
|
|
|
|
[Cached, Constant, Frozen]
|
|
|
|
readonly attribute sequence<MatchPattern> patterns;
|
|
|
|
};
|
|
|
|
|
|
|
|
dictionary MatchPatternOptions {
|
|
|
|
/**
|
|
|
|
* If true, the path portion of the pattern is ignored, and replaced with a
|
|
|
|
* wildcard. The `pattern` property is updated to reflect this.
|
|
|
|
*/
|
|
|
|
boolean ignorePath = false;
|
2018-04-18 21:02:05 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* If true, the set of schemes this pattern can match is restricted to
|
|
|
|
* those accessible by WebExtensions.
|
|
|
|
*/
|
|
|
|
boolean restrictSchemes = true;
|
Bug 1322235: Part 1 - Add native MatchPattern and MatchGlob bindings. r=billm,aswan
Bill, can you please review the binding code, and the general sanity of the
platform code. Andrew and zombie, can you please matching algorithms and
tests.
Change summary:
The existing JavaScript matching code works well overall, but it needs to be
called a lot, particularly from hot code paths. In most cases, the overhead of
the matching code on its own adds up enough to cause a problem. When we have
to call out to JavaScript via XPConnect to make a policy decision, it adds up
even more.
These classes solve both of these problems by a) being very fast, and b) being
accessible directly from C++. They are particularly optimized for the common
cases where only literal or prefix matches are required, and they take special
steps to avoid virtual calls wherever possible, and caching computed URL
values so that they can be reused across many match operations without
additional overhead.
MozReview-Commit-ID: BZzPZDQRnl
--HG--
rename : toolkit/modules/tests/xpcshell/test_MatchPattern.js => toolkit/components/extensions/test/xpcshell/test_MatchPattern.js
extra : rebase_source : c93c4c6c36460eb5ad0fc3aa86ad42a72e76bb6c
2017-05-24 21:57:29 +00:00
|
|
|
};
|