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-25 00:57:29 +03:00
|
|
|
/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2; -*- */
|
|
|
|
/* 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/. */
|
|
|
|
|
|
|
|
#ifndef mozilla_extensions_MatchPattern_h
|
|
|
|
#define mozilla_extensions_MatchPattern_h
|
|
|
|
|
|
|
|
#include "mozilla/dom/BindingDeclarations.h"
|
|
|
|
#include "mozilla/dom/MatchPatternBinding.h"
|
|
|
|
#include "mozilla/extensions/MatchGlob.h"
|
|
|
|
|
|
|
|
#include "jspubtd.h"
|
|
|
|
|
|
|
|
#include "mozilla/ClearOnShutdown.h"
|
|
|
|
#include "mozilla/Likely.h"
|
|
|
|
#include "mozilla/Maybe.h"
|
|
|
|
#include "mozilla/RefCounted.h"
|
|
|
|
#include "nsCOMPtr.h"
|
|
|
|
#include "nsCycleCollectionParticipant.h"
|
|
|
|
#include "nsTArray.h"
|
2017-10-03 01:05:19 +03:00
|
|
|
#include "nsAtom.h"
|
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-25 00:57:29 +03:00
|
|
|
#include "nsICookie2.h"
|
|
|
|
#include "nsISupports.h"
|
|
|
|
#include "nsIURI.h"
|
|
|
|
#include "nsWrapperCache.h"
|
|
|
|
|
|
|
|
|
|
|
|
namespace mozilla {
|
|
|
|
namespace extensions {
|
|
|
|
|
|
|
|
using dom::MatchPatternOptions;
|
|
|
|
|
|
|
|
|
|
|
|
// A sorted, binary-search-backed set of atoms, optimized for frequent lookups
|
|
|
|
// and infrequent updates.
|
|
|
|
class AtomSet final : public RefCounted<AtomSet>
|
|
|
|
{
|
2017-10-03 01:05:19 +03:00
|
|
|
using ArrayType = AutoTArray<RefPtr<nsAtom>, 1>;
|
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-25 00:57:29 +03:00
|
|
|
|
|
|
|
public:
|
|
|
|
MOZ_DECLARE_REFCOUNTED_TYPENAME(AtomSet)
|
|
|
|
|
|
|
|
explicit AtomSet(const nsTArray<nsString>& aElems);
|
|
|
|
|
|
|
|
explicit AtomSet(const char** aElems);
|
|
|
|
|
2017-10-03 01:05:19 +03:00
|
|
|
MOZ_IMPLICIT AtomSet(std::initializer_list<nsAtom*> aIL);
|
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-25 00:57:29 +03:00
|
|
|
|
|
|
|
bool Contains(const nsAString& elem) const
|
|
|
|
{
|
2017-10-03 01:05:19 +03:00
|
|
|
RefPtr<nsAtom> atom = NS_AtomizeMainThread(elem);
|
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-25 00:57:29 +03:00
|
|
|
return Contains(atom);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Contains(const nsACString& aElem) const
|
|
|
|
{
|
2017-10-03 01:05:19 +03:00
|
|
|
RefPtr<nsAtom> atom = NS_Atomize(aElem);
|
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-25 00:57:29 +03:00
|
|
|
return Contains(atom);
|
|
|
|
}
|
|
|
|
|
2017-10-03 01:05:19 +03:00
|
|
|
bool Contains(const nsAtom* aAtom) const
|
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-25 00:57:29 +03:00
|
|
|
{
|
2017-10-17 22:39:59 +03:00
|
|
|
return mElems.ContainsSorted(aAtom);
|
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-25 00:57:29 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
bool Intersects(const AtomSet& aOther) const;
|
|
|
|
|
|
|
|
|
2017-10-03 01:05:19 +03:00
|
|
|
void Add(nsAtom* aElem);
|
|
|
|
void Remove(nsAtom* aElem);
|
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-25 00:57:29 +03:00
|
|
|
|
|
|
|
void Add(const nsAString& aElem)
|
|
|
|
{
|
2017-10-03 01:05:19 +03:00
|
|
|
RefPtr<nsAtom> atom = NS_AtomizeMainThread(aElem);
|
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-25 00:57:29 +03:00
|
|
|
return Add(atom);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Remove(const nsAString& aElem)
|
|
|
|
{
|
2017-10-03 01:05:19 +03:00
|
|
|
RefPtr<nsAtom> atom = NS_AtomizeMainThread(aElem);
|
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-25 00:57:29 +03:00
|
|
|
return Remove(atom);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Returns a cached, statically-allocated matcher for the given set of
|
|
|
|
// literal strings.
|
|
|
|
template <const char** schemes>
|
|
|
|
static already_AddRefed<AtomSet>
|
|
|
|
Get()
|
|
|
|
{
|
|
|
|
static RefPtr<AtomSet> sMatcher;
|
|
|
|
|
|
|
|
if (MOZ_UNLIKELY(!sMatcher)) {
|
|
|
|
sMatcher = new AtomSet(schemes);
|
|
|
|
ClearOnShutdown(&sMatcher);
|
|
|
|
}
|
|
|
|
|
|
|
|
return do_AddRef(sMatcher);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
Get(nsTArray<nsString>& aResult) const
|
|
|
|
{
|
|
|
|
aResult.SetCapacity(mElems.Length());
|
|
|
|
|
|
|
|
for (const auto& atom : mElems) {
|
|
|
|
aResult.AppendElement(nsDependentAtomString(atom));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
auto begin() const
|
|
|
|
-> decltype(DeclVal<const ArrayType>().begin())
|
|
|
|
{
|
|
|
|
return mElems.begin();
|
|
|
|
}
|
|
|
|
|
|
|
|
auto end() const
|
|
|
|
-> decltype(DeclVal<const ArrayType>().end())
|
|
|
|
{
|
|
|
|
return mElems.end();
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
ArrayType mElems;
|
|
|
|
|
|
|
|
void SortAndUniquify();
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
// A helper class to lazily retrieve, transcode, and atomize certain URI
|
|
|
|
// properties the first time they're used, and cache the results, so that they
|
|
|
|
// can be used across multiple match operations.
|
2017-09-28 04:15:12 +03:00
|
|
|
class URLInfo final
|
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-25 00:57:29 +03:00
|
|
|
{
|
|
|
|
public:
|
|
|
|
MOZ_IMPLICIT URLInfo(nsIURI* aURI)
|
|
|
|
: mURI(aURI)
|
|
|
|
{
|
|
|
|
mHost.SetIsVoid(true);
|
|
|
|
}
|
|
|
|
|
2017-09-28 04:15:12 +03:00
|
|
|
URLInfo(nsIURI* aURI, bool aNoRef)
|
|
|
|
: URLInfo(aURI)
|
|
|
|
{
|
|
|
|
if (aNoRef) {
|
|
|
|
mURINoRef = mURI;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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-25 00:57:29 +03:00
|
|
|
URLInfo(const URLInfo& aOther)
|
|
|
|
: URLInfo(aOther.mURI.get())
|
|
|
|
{}
|
|
|
|
|
|
|
|
nsIURI* URI() const { return mURI; }
|
|
|
|
|
2017-10-03 01:05:19 +03:00
|
|
|
nsAtom* Scheme() const;
|
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-25 00:57:29 +03:00
|
|
|
const nsCString& Host() const;
|
2018-03-04 03:28:18 +03:00
|
|
|
const nsAtom* HostAtom() const;
|
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-25 00:57:29 +03:00
|
|
|
const nsString& Path() const;
|
|
|
|
const nsString& FilePath() const;
|
|
|
|
const nsString& Spec() const;
|
2017-09-28 04:15:12 +03:00
|
|
|
const nsCString& CSpec() const;
|
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-25 00:57:29 +03:00
|
|
|
|
|
|
|
bool InheritsPrincipal() const;
|
|
|
|
|
|
|
|
private:
|
|
|
|
nsIURI* URINoRef() const;
|
|
|
|
|
|
|
|
nsCOMPtr<nsIURI> mURI;
|
|
|
|
mutable nsCOMPtr<nsIURI> mURINoRef;
|
|
|
|
|
2017-10-03 01:05:19 +03:00
|
|
|
mutable RefPtr<nsAtom> mScheme;
|
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-25 00:57:29 +03:00
|
|
|
mutable nsCString mHost;
|
2018-03-04 03:28:18 +03:00
|
|
|
mutable RefPtr<nsAtom> mHostAtom;
|
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-25 00:57:29 +03:00
|
|
|
|
2017-09-28 04:15:12 +03:00
|
|
|
mutable nsString mPath;
|
|
|
|
mutable nsString mFilePath;
|
|
|
|
mutable nsString mSpec;
|
|
|
|
mutable nsCString mCSpec;
|
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-25 00:57:29 +03:00
|
|
|
|
|
|
|
mutable Maybe<bool> mInheritsPrincipal;
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
// Similar to URLInfo, but for cookies.
|
|
|
|
class MOZ_STACK_CLASS CookieInfo final
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
MOZ_IMPLICIT CookieInfo(nsICookie2* aCookie)
|
|
|
|
: mCookie(aCookie)
|
|
|
|
{}
|
|
|
|
|
|
|
|
bool IsSecure() const;
|
|
|
|
bool IsDomain() const;
|
|
|
|
|
|
|
|
const nsCString& Host() const;
|
|
|
|
const nsCString& RawHost() const;
|
|
|
|
|
|
|
|
private:
|
|
|
|
nsCOMPtr<nsICookie2> mCookie;
|
|
|
|
|
|
|
|
mutable Maybe<bool> mIsSecure;
|
|
|
|
mutable Maybe<bool> mIsDomain;
|
|
|
|
|
|
|
|
mutable nsCString mHost;
|
|
|
|
mutable nsCString mRawHost;
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
class MatchPattern final : public nsISupports
|
|
|
|
, public nsWrapperCache
|
|
|
|
{
|
|
|
|
NS_DECL_CYCLE_COLLECTING_ISUPPORTS
|
|
|
|
NS_DECL_CYCLE_COLLECTION_SCRIPT_HOLDER_CLASS(MatchPattern)
|
|
|
|
|
|
|
|
static already_AddRefed<MatchPattern>
|
|
|
|
Constructor(dom::GlobalObject& aGlobal,
|
|
|
|
const nsAString& aPattern,
|
|
|
|
const MatchPatternOptions& aOptions,
|
|
|
|
ErrorResult& aRv);
|
|
|
|
|
2017-09-07 07:56:45 +03:00
|
|
|
bool Matches(const nsAString& aURL, bool aExplicit, ErrorResult& aRv) const;
|
|
|
|
|
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-25 00:57:29 +03:00
|
|
|
bool Matches(const URLInfo& aURL, bool aExplicit = false) const;
|
|
|
|
|
2017-09-07 07:56:45 +03:00
|
|
|
bool Matches(const URLInfo& aURL, bool aExplicit, ErrorResult& aRv) const
|
|
|
|
{
|
|
|
|
return Matches(aURL, aExplicit);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
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-25 00:57:29 +03:00
|
|
|
bool MatchesCookie(const CookieInfo& aCookie) const;
|
|
|
|
|
|
|
|
bool MatchesDomain(const nsACString& aDomain) const;
|
|
|
|
|
|
|
|
bool Subsumes(const MatchPattern& aPattern) const;
|
|
|
|
|
|
|
|
bool Overlaps(const MatchPattern& aPattern) const;
|
|
|
|
|
|
|
|
bool DomainIsWildcard() const
|
|
|
|
{
|
|
|
|
return mMatchSubdomain && mDomain.IsEmpty();
|
|
|
|
}
|
|
|
|
|
|
|
|
void GetPattern(nsAString& aPattern) const
|
|
|
|
{
|
|
|
|
aPattern = mPattern;
|
|
|
|
}
|
|
|
|
|
|
|
|
nsISupports* GetParentObject() const { return mParent; }
|
|
|
|
|
|
|
|
virtual JSObject* WrapObject(JSContext* aCx, JS::HandleObject aGivenProto) override;
|
|
|
|
|
|
|
|
protected:
|
|
|
|
virtual ~MatchPattern() = default;
|
|
|
|
|
|
|
|
private:
|
|
|
|
explicit MatchPattern(nsISupports* aParent) : mParent(aParent) {}
|
|
|
|
|
2018-04-19 00:02:05 +03:00
|
|
|
void Init(JSContext* aCx, const nsAString& aPattern, bool aIgnorePath,
|
|
|
|
bool aRestrictSchemes, ErrorResult& aRv);
|
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-25 00:57:29 +03:00
|
|
|
|
|
|
|
bool SubsumesDomain(const MatchPattern& aPattern) const;
|
|
|
|
|
|
|
|
|
|
|
|
nsCOMPtr<nsISupports> mParent;
|
|
|
|
|
|
|
|
// The normalized match pattern string that this object represents.
|
|
|
|
nsString mPattern;
|
|
|
|
|
|
|
|
// The set of atomized URI schemes that this pattern matches.
|
|
|
|
RefPtr<AtomSet> mSchemes;
|
|
|
|
|
|
|
|
// The domain that this matcher matches. If mMatchSubdomain is false, only
|
|
|
|
// matches the exact domain. If it's true, matches the domain or any
|
|
|
|
// subdomain.
|
|
|
|
//
|
|
|
|
// For instance, "*.foo.com" gives mDomain = "foo.com" and mMatchSubdomain = true,
|
|
|
|
// and matches "foo.com" or "bar.foo.com" but not "barfoo.com".
|
|
|
|
//
|
|
|
|
// While "foo.com" gives mDomain = "foo.com" and mMatchSubdomain = false,
|
|
|
|
// and matches "foo.com" but not "bar.foo.com".
|
|
|
|
nsCString mDomain;
|
|
|
|
bool mMatchSubdomain = false;
|
|
|
|
|
|
|
|
// The glob against which the URL path must match. If null, the path is
|
|
|
|
// ignored entirely. If non-null, the path must match this glob.
|
|
|
|
RefPtr<MatchGlob> mPath;
|
2018-01-27 06:54:34 +03:00
|
|
|
|
|
|
|
public:
|
|
|
|
// A quick way to check if a particular URL matches <all_urls> without
|
|
|
|
// actually instantiating a MatchPattern
|
|
|
|
static bool MatchesAllURLs(const URLInfo& aURL);
|
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-25 00:57:29 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
class MatchPatternSet final : public nsISupports
|
|
|
|
, public nsWrapperCache
|
|
|
|
{
|
|
|
|
NS_DECL_CYCLE_COLLECTING_ISUPPORTS
|
|
|
|
NS_DECL_CYCLE_COLLECTION_SCRIPT_HOLDER_CLASS(MatchPatternSet)
|
|
|
|
|
|
|
|
using ArrayType = nsTArray<RefPtr<MatchPattern>>;
|
|
|
|
|
|
|
|
|
|
|
|
static already_AddRefed<MatchPatternSet>
|
|
|
|
Constructor(dom::GlobalObject& aGlobal,
|
|
|
|
const nsTArray<dom::OwningStringOrMatchPattern>& aPatterns,
|
|
|
|
const MatchPatternOptions& aOptions,
|
|
|
|
ErrorResult& aRv);
|
|
|
|
|
|
|
|
|
2017-09-07 07:56:45 +03:00
|
|
|
bool Matches(const nsAString& aURL, bool aExplicit, ErrorResult& aRv) const;
|
|
|
|
|
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-25 00:57:29 +03:00
|
|
|
bool Matches(const URLInfo& aURL, bool aExplicit = false) const;
|
|
|
|
|
2017-09-07 07:56:45 +03:00
|
|
|
bool Matches(const URLInfo& aURL, bool aExplicit, ErrorResult& aRv) const
|
|
|
|
{
|
|
|
|
return Matches(aURL, aExplicit);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
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-25 00:57:29 +03:00
|
|
|
bool MatchesCookie(const CookieInfo& aCookie) const;
|
|
|
|
|
|
|
|
bool Subsumes(const MatchPattern& aPattern) const;
|
|
|
|
|
|
|
|
bool Overlaps(const MatchPattern& aPattern) const;
|
|
|
|
|
|
|
|
bool Overlaps(const MatchPatternSet& aPatternSet) const;
|
|
|
|
|
|
|
|
bool OverlapsAll(const MatchPatternSet& aPatternSet) const;
|
|
|
|
|
|
|
|
void GetPatterns(ArrayType& aPatterns)
|
|
|
|
{
|
|
|
|
aPatterns.AppendElements(mPatterns);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
nsISupports* GetParentObject() const { return mParent; }
|
|
|
|
|
|
|
|
virtual JSObject* WrapObject(JSContext* aCx, JS::HandleObject aGivenProto) override;
|
|
|
|
|
|
|
|
protected:
|
|
|
|
virtual ~MatchPatternSet() = default;
|
|
|
|
|
|
|
|
private:
|
|
|
|
explicit MatchPatternSet(nsISupports* aParent, ArrayType&& aPatterns)
|
|
|
|
: mParent(aParent)
|
2018-06-01 19:30:30 +03:00
|
|
|
, mPatterns(std::forward<ArrayType>(aPatterns))
|
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-25 00:57:29 +03:00
|
|
|
{}
|
|
|
|
|
|
|
|
nsCOMPtr<nsISupports> mParent;
|
|
|
|
|
|
|
|
ArrayType mPatterns;
|
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace extensions
|
|
|
|
} // namespace mozilla
|
|
|
|
|
|
|
|
#endif // mozilla_extensions_MatchPattern_h
|