Web extensions etc use these to clean up their menu items, for example.
For context menus there's no need to fire popupshowing, it's been done
by the popup manager already.
Differential Revision: https://phabricator.services.mozilla.com/D140522
After enabling bytecode cache for module script, we need to handle
the SRI mismatch on bytecode cache, that requires reloading the script source
again.
Differential Revision: https://phabricator.services.mozilla.com/D140551
The module scripts are scanned immediately before executing, and if the
module script is not yet executed, and it matches the requirement for encoding
(size, fetch count, etc), it's marked as encode,
and they're scanned again immediately after executing, and marked scripts are
queued for bytecode encoding.
This patch doesn't actually enable the encoding, given ShouldCacheBytecode
returns false because the caching is not enabled for the channel and
GetCacheTokenFetchCount fails.
Differential Revision: https://phabricator.services.mozilla.com/D140296
As a preparation to use the bytecode encoding in the module evaluation code,
ScriptLoader::MaybePrepareForBytecodeEncoding is split into 2 parts:
* one for performing preparation before executing script
* one for queuing the request for bytecode encoding after executing script
In module's case, the bytecode encoding handling must be done on the entire
import tree, and also the module object's ScriptSlot is cleared on execution.
So, the script reference must be copied to the corresponding script load request
field before execution, and the script source must be queued for bytecode
encoding after executing the top-level script, so that incremental encoding
reflects functions called there.
Differential Revision: https://phabricator.services.mozilla.com/D140295
Module's ScriptSlot is cleared after evaluating the top-level script.
In order to skip modules imported multiple times when encoding, added
JS::IsModuleEvaluated.
Differential Revision: https://phabricator.services.mozilla.com/D140294
Module bytecode should use different MIME type, to avoid mixing up script/module
bytecodes for single JS file.
This patch adds a static method that simply returns the current bytecode MIME
type.
The later patch adds a new MIME type for module bytecode and modify the
ScriptLoader::BytecodeMimeTypeFor method to return corresponding MIME type.
Differential Revision: https://phabricator.services.mozilla.com/D140292
To add conditional JS::StartIncrementalEncoding, and also to add a bytecode
decoding branch, replace nsJSUtils::CompileModule with raw JSAPI calls with
Stencil.
Differential Revision: https://phabricator.services.mozilla.com/D140291
As a preparation to add bytecode case to CompileOrFinishModuleScript, removed
the shared nsresult variable and make each branch directly return, and also
do early return for error case.
Differential Revision: https://phabricator.services.mozilla.com/D140290
mScript field is used only for bytecode encoding, and this field is used as a
flag for whether the script load request has bytecode-encoding-related
references.
Differential Revision: https://phabricator.services.mozilla.com/D140288
test_ext_contexts_gc.js calls Assert.ok(context, "..."). That in turn
computes the assert message (even if the assert passes), by calling
JSON.stringify(context).
The context object here is really complex and serialization depends on
the component order because it holds a Cu.Sandbox object among other
stuff. If enumerating a member throws, then we don't get to enumerate
other potentially problematic stuff.
But changing the order of enumeration made it so that we enumerated
nsFocusManager.activeWindow _before_ throwing, which asserts in debug
builds getting my previous patch backed out. Amazing.
Depends on D140975
Differential Revision: https://phabricator.services.mozilla.com/D141057
This adds just the boilerplate, and doesn't implement the OS-specific
bits. It's still useful tho.
Co-Authored-By: Greg Tatum <tatum.creative@gmail.com>
Differential Revision: https://phabricator.services.mozilla.com/D140975
IsSyncPagePrinting() only had one implementation which unconditionally
returned true.
So, any code that was conditioned on !IsSyncPagePrinting() is necessarily
dead/unreachable.
These are also crashing due to a null deref in mPrintTarget which might
happen if print is aborted.
Differential Revision: https://phabricator.services.mozilla.com/D140988
This also reorders the colorspace if-elses to explicitly check for bt601,
bt709, and bt2020 in that order. This ensures that anything with the Identity
colorspace will be left with no attachments.
Differential Revision: https://phabricator.services.mozilla.com/D140576
Position needs to be relative to the GdkWindow.
On Wayland, where there are no global screen coordinates that already
worked, but on X11 it didn't.
Differential Revision: https://phabricator.services.mozilla.com/D140520
This adds just the boilerplate, and doesn't implement the OS-specific
bits. It's still useful tho.
Co-Authored-By: Greg Tatum <tatum.creative@gmail.com>
Differential Revision: https://phabricator.services.mozilla.com/D140975
An alternative would be to adjust the test expectation to not include
the trailing newline, but this seemed more likely to be what the test
wanted to test.
Differential Revision: https://phabricator.services.mozilla.com/D140954
See bug 1741740 for a case where this caused issues.
It doesn't react to pointer-events by default so it also makes sense for
it to not be selectable. Also, our selection code doesn't deal
particularly well with anonymous content being selected, specially in a
non-independent selection.
Differential Revision: https://phabricator.services.mozilla.com/D140830
