This functionality was already added to Gecko for UA stylesheets allow the "dom.details_element.enabled" preference to work. I changed the condition to allow bool preferences to be used in chrome stylesheets as well.
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.
With the changes to layout for WebComponents, it is now apparently possible to
pass in null for frame tree items to this function, which would cause a null
deref crash if not checked.
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.
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.
Overflow properties have two purposes:
1. controlling whether the scrollbar should be shown;
2. controlling whether the content is scrollable.
However, with the scrollbar-width property being added, scrollability and
presence of a scrollbar are no longer tied together.
This patch makes a separation between the value of overflow and the presence of
a scrollbar by making it clear that for ScrollReflowInput, we only care about
whether scrollbar should be shown.
This should make it easier to write the logic involving presence of the
scrollbar based on webdev choice.
While we do fail a couple of tests, the other mainstream browsers also fail them and I think our implementation of tab-size is good enough to be unprefixed at this point. Having this patch also makes testing easier.
