We're currently fairly vague and inconsistent about the values we provide to
content policy implementations for requestOrigin and requestPrincipal. In some
cases they're the triggering principal, sometimes the loading principal,
sometimes the channel principal.
Our existing content policy implementations which require or expect a loading
principal currently retrieve it from the context node. Since no current
callers require the principal to be the loading principal, and some already
expect it to be the triggering principal (which there's currently no other way
to retrieve), I chose to pass the triggering principal whenever possible, but
use the loading principal to determine the origin URL.
As a follow-up, I'd like to change the nsIContentPolicy interface to
explicitly receive loading and triggering principals, or possibly just
LoadInfo instances, rather than poorly-defined request
origin/principal/context args. But since that may cause trouble for
comm-central, I'd rather not do it as part of this bug.
MozReview-Commit-ID: LqD9GxdzMte
This parameter isn't used by any implementation of onDispatchedEvent,
and keeping the parameter makes later refactorings in this bug more difficult.
MozReview-Commit-ID: 90VY2vYtwCW
When loading a style sheet, if the SourceMap (or legacy X-SourceMap)
response header was seen, record it and make it available to chrome
scripts.
MozReview-Commit-ID: 3wtUADzgrI3
As I've said before, as module owner I prefer that MOZ_ASSERT_IF not be
used in the module because I consider it to be unreadable. However, a
few uses have crept in, and this patch removes them.
I consider it to be unreadable because the name looks like a name that
uses smalltalk-ish naming conventions, i.e., with a part of the name
corresponding to each parameter, in order. However, the parameters are
in the order opposite the name.
This was written primarily with the vim commands:
:%s/MOZ_ASSERT_IF(\([^,]*\),/MOZ_ASSERT(!\1 ||/
:wn
followed by manual cleanup for indentation and removal of !!.
MozReview-Commit-ID: G6rLbOn7k8d
It seems no one actually care about the order of the list, and the order
is completely meaningless if the script insert new @import rules.
Changing the order makes inserting faster, and make it easier for later
patch to get the latest inserted child sheet.
MozReview-Commit-ID: 72eKqVoPbZ7
I've propagated quirks mode information on some places. But we needed to pass
quirks mode to some other FFI functions to be able to handle that information
properly.
MozReview-Commit-ID: JovQWjN3YJx
This is necessary because if we pass in the import rule, we would need
to invoke Servo_ImportRule_GetSheet to get the child sheet. However,
Servo_ImportRule_GetSheet tries to lock the global rwlock with read
access, while Servo_CssRules_InsertRule has already locked the same
rwlock with write access for the CSSOM case.
Since the import rule itself is never needed in the code path, it is
easier to just pass in the child stylesheet.
MozReview-Commit-ID: 4njNyGniPIm
These changes allow us to asynchronously load pre-loaded stylesheets, in a way
that's similar to ChromeUtils.compileScript. The new method returns a Promise
which resolves to the preloaded sheet once it's finished loading.
This will allow us to remove the last remaining use of synchronous channels in
moz-extension: URLs.
MozReview-Commit-ID: 7J52ff93YKT
When constructing a Loader without passing a document, we added a DocGroup
parameter so that we could still use it to dispatch events to the DocGroup.
Delete NS_ENSURE_TRUE because new() is infallable.
Use another runnable pointer for calling dispatching because forget() will
nuke the pointer and we need to use evt afterwards.
MozReview-Commit-ID: Ce2K6j4pUhA
