* Use NonAssertingLabel in BaselineInterpreterHandler, similar to BaselineCodeGen fields.
* Make addDebugInstrumentationOffset report OOM.
No test case because the fuzz test is huge and this patch is based on the stack traces.
Differential Revision: https://phabricator.services.mozilla.com/D53630
--HG--
extra : moz-landing-system : lando
The patch changes InputStreamShim::AsyncWait() so it checks the buffer state and if there is some data available the callback is immediately notified. Without this check the callback would be notified only when new data is delivered from the network.
Differential Revision: https://phabricator.services.mozilla.com/D53972
--HG--
extra : moz-landing-system : lando
This should specifically prevent bug 1553938 from happening in the
future. Unfortunately it won't prevent other similar bugs from
happening.
Differential Revision: https://phabricator.services.mozilla.com/D52463
--HG--
extra : moz-landing-system : lando
It turns out that we don't actually want to install js-confdefs.h
because it contains macro definitions that can conflict when embedders
include JSAPI headers in their Autotools projects.
Differential Revision: https://phabricator.services.mozilla.com/D52462
--HG--
extra : moz-landing-system : lando
Whether ENABLE_INTL_API and ENABLE_TYPED_OBJECTS are defined, affects
the behaviour of JS_FOR_PROTOTYPES for the prototypes of Intl and
TypedObject. Therefore, these macros have to be available to embedders.
Rename them to JS_HAS_INTL_API and JS_HAS_TYPED_OBJECTS (in line with
the existing JS_HAS_CTYPES) everywhere they are used, and add them to
js-config.h.in.
Differential Revision: https://phabricator.services.mozilla.com/D52461
--HG--
extra : moz-landing-system : lando
Previously, if SpiderMonkey embedders linked to a copy of libmozjs built
with --enable-cranelift, --enable-wasm-gc, or --enable-fuzzing, then the
size of the ContextOptions data structure declared in the header file
would be different than the size of ContextOptions in the library,
likely leading to crashes. This makes all members of ContextOptions
independent of preprocessor macros. Any options not compiled into
SpiderMonkey will still be no-ops.
Differential Revision: https://phabricator.services.mozilla.com/D52460
--HG--
extra : moz-landing-system : lando
These are configure macros that start with JS_ and have an effect on the
public API declared in JSAPI header files, so they should be included in
the installed js-config.h header file.
Differential Revision: https://phabricator.services.mozilla.com/D52459
--HG--
extra : moz-landing-system : lando
If only relying on JS_64BIT to determine whether the system is 64-bits,
then the result will be incorrect when the header is installed as a
public header for use by embedders, and since JS_BITS_PER_WORD affects
the layout of structs in header files, things will go badly wrong.
This uses two other ways of determining pointer width, hopefully
cross-platform enough. __SIZEOF_POINTER__ is a GCC-ism and probably
works in Clang as well. UINTPTR_MAX is hopefully sufficiently
cross-platform as a last resort.
Differential Revision: https://phabricator.services.mozilla.com/D52458
--HG--
extra : moz-landing-system : lando
We should have the same public API available whenever possible, and make
it a no-op or make it throw immediately if JS was built without support
for it, instead of showing or hiding the API in header files using
configure macros. Otherwise embedders can easily get mismatches between
a library with functionality and header files without it, or vice versa.
There was no good reason why JS_GetErrorType() was nightly-only API, so
this also enables it unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D52124
--HG--
extra : moz-landing-system : lando
This should have been obvious; we didn't end up declaring ElementType on WeakHeapPtr.
Differential Revision: https://phabricator.services.mozilla.com/D54552
--HG--
extra : moz-landing-system : lando
More use is being made of C++ move semantics recently and this imporves support for moving our GC wrapper types. In this case we don't want to trigger the pre-barrier on the source of the move because we are not modifying the object graph. We also do not want to check that wrapper contents are non gray, because this is valid (it's not valid to *create* a new heap pointer to a GC thing).
The patch adds a release() method to wrappers that returns the original contents of the wrapper after clearing it, without triggering a pre-barrier. Also it adds setUnchecked() methods to set wrapper contents without the gray marking check.
Differential Revision: https://phabricator.services.mozilla.com/D54305
--HG--
extra : moz-landing-system : lando
The crash occurs when dispatching a user input event which is a default action
of a raw user input event like `click` event caused by `mouseup` event if
the raw event's `isTrusted` is set to `false` accidentally during dispatch.
User input events are fired in the main process first. Then,
`EventStateManager` sends it to remote process from `PostHandleEvent()` if
necessary. However, at this time, `WidgetEvent::mFlags::mDispatchedAtLeastOnce`
is never rest, but its only referrer, `EventDispatcher::DispatchDOMEvent()`
assumes that when it's `true`, `WidgetEvent::mFlags:mIsBeingDispatched` is
`false`. Therefore, only in content process, `mouseup` event's `isTrusted` is
set to `false` by `EventTarget.dispatchEvent()` even while it's being dispatch.
And also the trusted state will be used for creating next event which is part
of the default action.
https://searchfox.org/mozilla-central/rev/6566d92dd46417a2f57e75c515135ebe84c9cef5/dom/events/EventDispatcher.cpp#1121,1126,1130-1131,1135,1138,1143
Therefore, this patch makes `WidgetEvent::mFlags` reset `mDispatchedAtLeastOnce`
when it's copied across process boundary and make
`EventDispatcher::DispatchDOMEvent()` won't modify being dispatched events for
avoiding any odd issues.
Unfortunately, this patch adds "expected: FAIL" to the new WPT test only on
Windows. The failure reason is still unclear. I cannot reproduce the failure
on my Windows environment, but on Try Server, it fails permanently since
the driver succeeds to send the mouse click, but the button never receives
`mouseup` nor `click` event.
Differential Revision: https://phabricator.services.mozilla.com/D52988
--HG--
extra : moz-landing-system : lando
The page was outdated and incorrect, so we remove it.
The architecture diagram of the console is updated to
show TabBoxPanel, and we add a quick summary for the
external components used in the Console.
Differential Revision: https://phabricator.services.mozilla.com/D54463
--HG--
extra : moz-landing-system : lando
2019-11-20 Kevin Jacobs <kjacobs@mozilla.com>
* lib/ssl/ssl3con.c, lib/ssl/tls13con.c:
Bug 1590001 - Prevent negotiation of versions lower than 1.3 after
HelloRetryRequest. r=mt
This patch prevents negotiation of TLS versions lower than 1.3 after
an HRR has been sent.
[d64102b76a43] [tip]
2019-11-22 J.C. Jones <jjones@mozilla.com>
* lib/softoken/pkcs11u.c:
Bug 1596450 - Fixup, coverity CID 1455952 r=kjacobs
[46b1355d8765]
* lib/pk11wrap/pk11slot.c:
Bug 1522203 - Remove Pentium Pro workaround for PK11_GetAllTokens
r=kjacobs
The comment indicated the wasted effort was to work around a cache
issue on the Pentium Pro. I think it has served its purpose.
[27d9fb4ac69b]
2019-11-21 Franziskus Kiefer <franziskuskiefer@gmail.com>
* tests/gtests/gtests.sh:
Bug 1592557 - fix prng kat tests, r=jcj
fix for prng kat tests
[474334bb790b]
2019-11-20 Robert Relyea <rrelyea@redhat.com>
* lib/softoken/pkcs11c.c, lib/softoken/pkcs11i.h,
lib/softoken/sftkhmac.c:
Bug 1596450 - softoken: unified MAC implementation patch by Alex
Scheel review by rrelyea
[3147585149f0]
Differential Revision: https://phabricator.services.mozilla.com/D54637
--HG--
extra : moz-landing-system : lando
This should specifically prevent bug 1553938 from happening in the
future. Unfortunately it won't prevent other similar bugs from
happening.
Differential Revision: https://phabricator.services.mozilla.com/D52463
--HG--
extra : moz-landing-system : lando
It turns out that we don't actually want to install js-confdefs.h
because it contains macro definitions that can conflict when embedders
include JSAPI headers in their Autotools projects.
Differential Revision: https://phabricator.services.mozilla.com/D52462
--HG--
extra : moz-landing-system : lando
Whether ENABLE_INTL_API and ENABLE_TYPED_OBJECTS are defined, affects
the behaviour of JS_FOR_PROTOTYPES for the prototypes of Intl and
TypedObject. Therefore, these macros have to be available to embedders.
Rename them to JS_HAS_INTL_API and JS_HAS_TYPED_OBJECTS (in line with
the existing JS_HAS_CTYPES) everywhere they are used, and add them to
js-config.h.in.
Differential Revision: https://phabricator.services.mozilla.com/D52461
--HG--
extra : moz-landing-system : lando
Previously, if SpiderMonkey embedders linked to a copy of libmozjs built
with --enable-cranelift, --enable-wasm-gc, or --enable-fuzzing, then the
size of the ContextOptions data structure declared in the header file
would be different than the size of ContextOptions in the library,
likely leading to crashes. This makes all members of ContextOptions
independent of preprocessor macros. Any options not compiled into
SpiderMonkey will still be no-ops.
Differential Revision: https://phabricator.services.mozilla.com/D52460
--HG--
extra : moz-landing-system : lando
These are configure macros that start with JS_ and have an effect on the
public API declared in JSAPI header files, so they should be included in
the installed js-config.h header file.
Differential Revision: https://phabricator.services.mozilla.com/D52459
--HG--
extra : moz-landing-system : lando
If only relying on JS_64BIT to determine whether the system is 64-bits,
then the result will be incorrect when the header is installed as a
public header for use by embedders, and since JS_BITS_PER_WORD affects
the layout of structs in header files, things will go badly wrong.
This uses two other ways of determining pointer width, hopefully
cross-platform enough. __SIZEOF_POINTER__ is a GCC-ism and probably
works in Clang as well. UINTPTR_MAX is hopefully sufficiently
cross-platform as a last resort.
Differential Revision: https://phabricator.services.mozilla.com/D52458
--HG--
extra : moz-landing-system : lando
We should have the same public API available whenever possible, and make
it a no-op or make it throw immediately if JS was built without support
for it, instead of showing or hiding the API in header files using
configure macros. Otherwise embedders can easily get mismatches between
a library with functionality and header files without it, or vice versa.
There was no good reason why JS_GetErrorType() was nightly-only API, so
this also enables it unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D52124
--HG--
extra : moz-landing-system : lando
The previous site URI is now only written on the parent and sent back to the child once all redirects have completed.
In a follow up we will also transfer this information when a process switch occur as it's currently broken.
Differential Revision: https://phabricator.services.mozilla.com/D53926
--HG--
extra : moz-landing-system : lando
