Of course it couldn't be trivial :P
wrapObject is a pure virtual function which prevents an abstract constructor
from being used.
So, we need to extend DOMEventTargetHelper (applicable acronym: DETH :D) with
a wrapObject implementation - in a derivative class is the clearest way to do
this, as opposed to making DETH more complex.
This removes some restrictions on whether an interface that implements
QueryInterface can have a non-abstract ancestor.
This restriction was put in place back when we automatically added
QueryInterface to all rootmost non-abstract interfaces (~Pale Moon 24).
At the time, we needed to make sure it did NOT end up on EventTarget, because
back then WebIDL quickstubs would replace the QI implementation on non-WebIDL
EventTargets with the WebIDL one, which would not work for them.
Since then, we have removed WebIDL quickstubs and we now explicitly list which
interfaces get QueryInterface, so this check is no longer needed.
This adds the later spec revision's contentBoxSize and borderBoxSize, and the
inlineSize and blockSize concepts.
The older spec contentRect remains functional as well for backwards
compatibility with the earlier spec (that was IMHO perfectly fine as it was...)
GetNodeDepth() is a specialized version for ResizeObserver to get the depth of
a node across Shadow DOM. It's better to have this in ResizeObserver.cpp
instead of the generic ContentUtils.
Also updated the function to bypass the shadow root itself and not count it
because ResizeObserver doesn't observe the shadow root and only needs the
relative depths among all observed targets. IOW we use the flattened tree here.
Apparently Mozilla completely spaced out on this when adding the CSP nonce
mechanism, potentially causing web compat issues if scripting relies on
being able to get/set nonces through DOM and/or causing CSP policy check
issues if websites try to "hide" nonces.
The removal of this preference was botched, all other surrounding plumbing changes appear to be working okay. The ability to use prefs to control this stylesheet might be useful in the future, so perhaps this is one of those "if it ain't broke, don't fix it" bugs where leaving well enough alone in the first place would have been the best choice.
This PR passes all current tests for this feature, and implements the "prefers-color-scheme" media query as an enumerated keyword that is controlled by an integer preference.
Currently, the possible options are 0 to see a website's fallback code and essentially behave like this isn't implemented (our current behavior), 1 to express a preference for a light theme (the default for spec reasons), and 2 to express a preference for a dark theme. Over time, this list may expand to include other preferences like a preference for a sepia theme or something, and this leaves us prepared for that future.
