Mostly making parts conditional and removing blocks that are no longer
applicable, and a few minor edits otherwise to update links and text.
Resolves#1722
- Use some pointer voodoo and instead of stringbuffer append()
- Use a lookup table instead of char comparisons for chr < 256
- Stop using a Hashtable/MovableCellHasher for JSON CycleDetector
This had been initially dealt with in issue #1699's commits, but one of them
was in the end reverted, which caused this problem (this change should have
been done there).
Defining _POSIX_C_SOURCE to 199309L on FreeBSD causes compile errors, because of
an obscure interaction between system wrappers and libc++ headers. The source
doesn't seem to need it at all, which tests confirm.
I bet that this is not needed either on other modern systems (even those based
on glibc), and that the define could probably be entirely removed. Not trying
it because I can't test it myself.
New FreeBSD versions have introduced RTLD_DEEPBIND (see dlopen(3)), which
triggers a provoked build error to be on the "safe" side.
Indeed, improper use of RTLD_DEEPBIND could cause malloc interposing not to
work on specific libraries. This would happen for libraries that provide their
own malloc/free and exchange pointers with other libraries or the main program,
one allocating an area and another one deallocating it.
It seems it happened for glibc, which is not a concern on FreeBSD, and for the
Flash Player (not a concern either, there is no native Flash Player). Moreover,
there is only a single reference to RTLD_DEEPBIND in the whole platform
currently, namely in the WebRTC code, but the corresponding code chunk is
compiled-in only on Linux (and this library doesn't seem to redefine malloc
functions anyway). So I don't see how a problem could happen. Additionally,
Pale Moon, which is my focus, doesn't use WebRTC.
Corresponding Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=493541
Including <cstdlib> must never trigger inclusion of "mozalloc.h", because the
first thing this one does is precisely to include <cstdlib>.
It is now the case that, in libc++ 9 and beyond, <cstdlib> includes <math.h>
which then tries to include <type_traits>, which the STL wrapper intercepts,
trying to load "mozalloc.h". Same problem happens with <limits>.
Fix pulled from: https://bugzilla.mozilla.org/show_bug.cgi?id=1594027.
This change makes unicode line and paragraph separators allowed in JS strings,
removing the only quirk of the JS string definition that made JSON not a valid
subset of JS.
Resolves#1732
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.
