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.
This is probably the last thing we will ship (if ever) since it needs the most
spec and implementation work for arbitrary use that is pretty far into a corner.
This feature should not be shipped until the various definitions of addition for
each additive property are properly specified and then implemented accordingly.
Unlike other patches in this series, compositing is not frequently used
internally so there is no need to enable this by default for chrome callers.
This preference controls whether authors are allowed to specify animations
without a 0% or 100% keyframe.
We intend to ship this but it isn't implemented yet (needs a follow-up) but this
preference acts as a safeguard in case we discover we need to disable it once
it's implemented.
ScrollbarStyles contains values of overflow, (over)scroll-behavior, etc.
The only one which is marginally related to scroll _bars_ is overflow, which can
be used to hide scrollbar (by making an element not scrollable) or enforce the
scrollbar to display.
It makes more sense to be called ScrollStyles as it's mainly concerning behavior
of scrolling, not scrollbars. Also, with the addition of scrollbar width
properties, the current name can be confusing.
