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.
Transplanting objects is inherently oom-unsafe, so add
`AutoEnterOOMUnsafeRegion` to `JS_TransplantObject()` and annotate crashes
accordingly if they do happen.
- Enabled SVG transform-box property. I've tested this extensively including the
bug that prevented Mozilla from shipping until 55 which does not seem to apply
to us (most likely a stylo issue). Should be good to go.
- Moved the getRootNode pref to a better place (no change)
- Enabled inputmode property for forms. This is n/a for physical keyboards but
should improve the experience for soft keyboards that can pop up various forms
of input (e.g. numeric) depending on the mode indicated. According to BZ this is
feature complete at our level but was problematic for Android which we don't
have support for anyway.
- Restricted crashing on insecure input of text to debug only.
- Enabled shutting down the async OSFile worker if not used for 30 seconds to
be more conscientious about resource use.
- Enabled blocking of autoplay of media in the background by default, since it
is a saner default to have for the OOBE and is commonly a desired setting by
users (see forum).
- Disabled the storage manager API by default. This fine-grained control over
stored website data is already handled by various extensions and we don't have
the front-end support for it. Assuming this was necessary for Mozilla due to
limited access of WebExtensions to this kind of data.
This enables the DOM Animations API core functions with the exception of those
parts that are either unimplemented or not ready for use, which have been
preffed off in this issue's previous parts.
Also tag #1319 for enabling a previous RELEASE_OR_BETA shielded API.
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.
This would interfere with implementing thin scrollbars.
Almost all widgets provide a non-overridable size for scrollbar buttons, so it
makes no sense to specify min size for them. It is probably(?) a layout bug that
min size properties can override the value returned by GetMinimumWidgetSize
even if aIsOverridable is set to false, but removing this rule is simpler than
locating and fixing the issue in layout code ;)
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.