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), a choice was made
to pass the triggering principal whenever possible, but use the loading
principal to determine the origin URL.
Since the local variable is always initialized to false, we don't actually need to declare it and can just pass "false" directly as a parameter to the PrepareSheet function's bool. I was worried about code readability at first, but some well-placed comments took care of that.
This clarifies the assumptions the code is making and the order in which the variables pass through the loading process. The new variable is set after the sheet is created and prepared, and is assumed to be false in the beginning.
This part of the bug was significantly complicated by the following major refactors:
https://bugzilla.mozilla.org/show_bug.cgi?id=1456435https://bugzilla.mozilla.org/show_bug.cgi?id=1459498
As best as I can tell, we just need to implement the explicitly enabled
flag on every instance of GetStyleSheetInfo, make sure
aIsExplicitlyEnabled is false in every situation except the one where
the disabled content attribute is removed from a link element, and
enable alternate stylesheets if this flag is set on them. So we take the
explicitly enabled flag as an input to PrepareSheet, and also add it to
LoadStyleLink and LoadInlineStyle. I also decided not to defer loading of
alternate stylesheets that have been explicitly enabled.
Moonchild
FranklinDM
Brian Smith
athenian200
wolfbeast
Matt A. Tobin
roytam1