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.
Coded a simple memory allocator meant to be used during jemalloc bootstrap
(malloc_init_hard()). Although protected by "#ifdef __FreeBSD__", it is not
FreeBSD-specific: Any POSIX platform could use it.
Hook it so that it is used in place of jemalloc's own routines while
malloc_init_hard() is executing or memory for mutexes is being
allocated. Currently, 'malloc', 'calloc', '*memalign' and 'free' are diverted
during init or lock initializations.
Details are quite complex, see the big comment block starting with "There are
several problematic interactions between FreeBSD's libthr and this jemalloc."
for more explanations.
Also replaced ad-hoc BSD code to determine the number of CPUs with 'sysconf',
which is POSIX-compliant (and supported on modern BSDs).
In fact, this is a security threat.
This function calls 'arc4random_addrandom', which was removed from the
reference implementation 7 years go [1], on the ground that this was in fact an
internal interface which is almost impossible to use correctly. This update has
since then been propagated to other implementations (e.g., FreeBSD, IllumOS,
Android).
Do this for all platforms, since 'evutil_secure_rng_add_bytes' is not even used
in the current tree, and for the reason stated above, should never be.
Related bugs at Mozilla and libevent: Links [2] and [3] below.
[1] http://marc.info/?l=openbsd-cvs&m=138238762705209&w=2
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=931354
[3] https://sourceforge.net/p/levent/bugs/320/
This changes the toolkit theme for Linux and Windows (Mac already did this) to
style the input textbox on the findbar with -moz-appearance:none so as to give
us styling control (as opposed to using a native widget style) and apply a
neutral style to it.
Also ensures Mac remains readable in case of poorly contrasting text.
