This fixes bug 1799460 for good. You can test this on Win10 with
browser.display.windows.non_native_menus=0 or HCM, but same applies to
Win7/8.
The front-end sets their own sizes anyways, and when the windows sizes
are less than the ones the front-end sets, we see that bug.
This is rather annoying because, even though it's fixable (we can fix
the intrinsic sizing code in the web to deal with this properly), it's
probably not worth fixing, as no web-exposed widget has a min-widget
size other than scrollbars and internal form control parts.
Removing this code altogether just works, since as I said before the
front-end sizes the menu parts anyways, so enforcing a given size in C++
is not necessary.
Differential Revision: https://phabricator.services.mozilla.com/D162709
We used to provide links to the bug numbers but this was broken
somewhere along the way. Now it is provided the failure IDs from which
it can attempt to extract a bug number, as well as always display any
failure ID and message whenever possible.
Differential Revision: https://phabricator.services.mozilla.com/D162734
Tested by toolkit/components/places/tests/bookmarks/test_bookmarks_reorder.js
Note the "parent/sync" annotation and PlacesSyncUtils.order() are no more used,
a bug apart will be filed to remove them.
Differential Revision: https://phabricator.services.mozilla.com/D162270
Based on https://phabricator.services.mozilla.com/D141582. Updates the bookmark toolbar to delay creating new bookmarks and folders while "delayed apply" mode is enabled.
One edge case which is not currently accounted for, is the case where user clicks on "Bookmark All Tabs", and then creates folders from within the dialog box, for example:
{F4228947}
In this case, the new folders will be created instantly, even if delayed apply is enabled. Cancelling the dialog box will remove them. (This is why we still need to use "batching", even in delayed apply mode.)
Because of how the dialog is currently structured, it seems fairly complex to handle this case. I am not sure if it is within the scope of this project, open to advice.
Differential Revision: https://phabricator.services.mozilla.com/D160554
Devtools can generate fetch request on behalf of the content document,
reporting these requests in PerformanceObserver would cause confusion,
so we should ignore them.
Differential Revision: https://phabricator.services.mozilla.com/D162582
This includes WebTransport, WebTransportSendStream,
WebTransportReceiveStreams, WebTransportBidirectionalStream and
WebTransportError classes without any actual functionality
Differential Revision: https://phabricator.services.mozilla.com/D162323
This patch adds alias set annotations to the MIR generated for
struct.{new,set,get}, so as to enable the existing GVN machinery to remove
duplicate loads of the OOL block pointer in the (static) presence of multiple
OOL field accesses to the same wasm object.
This is a bit tricky because we must ensure that neither an IL-data-field nor
OOL-data-field write to the object invalidate the OOL-block-pointer read.
Hence the OOL-block-pointer-field cannot be in the same alias set as either
the IL- nor OOL-data fields. And so this patch adds three new alias-set
descriptors.
The implementation is straightforward and described in comments.
Because it is easy to mess up optimisation with incorrect alias set
descriptors, the `MWasm{Load,Store}Field*::New` methods heavily restrict
what descriptors they accept, via assertions.
Because those same MIR nodes are also used to implement exceptions, they also
accept `AliasSet::{Load,Store}(AliasSet::All)` ("no information") descriptors.
The exception-handling MIR is unaffected by this patch.
Differential Revision: https://phabricator.services.mozilla.com/D161254
This patch implements struct.{new,set,get} and ref.cast for Ion. The
implementation is in principle straightforward and is derived from the
baseline equivalents. There are however many pieces that need to be
coordinated. Changes:
* Compiler gating logic -- enable Ion for wasm GC extensions.
* Pertaining to the above, extend the guard conditions in many of the wasm/gc
test cases so as to limit them to baseline only, for now, so that we don't
get failures as a result of gc insns that are currently unimplemented in
Ion. This will need to be incrementally undone as more gc insns get
implemented in Ion.
* Pertaining to testing (lib/wasm-binary.js), remove wasm gc opcodes from the
lists of opcodes that we check are unimplemented.
* New test file wasm/gc/structs2.js, that tests 8- and 16-bit field accesses,
since the existing structs.js file doesn't.
* Add support to MIR and LIR to handle 8- and 16-bit memory accesses. One
possibility would have been to add MIRType::Int16 and MIRType::Int8, but I
didn't want to destabilise the existing, probably carefully-balanced MIR
optimisation machinery for JS. So I chose to add auxiliary descriptors just
for the 4 relevant MIR/LIR nodes instead:
- New enums MNarrowingOp and MWideningOp, to describe how to narrow to /
widen from Int32.
- Renamed wasm::FieldExtension to wasm::FieldWideningOp for consistency with
the above. Note MWideningOp and wasm::FieldWideningOp both need to exist;
neither can exactly do the job of the other.
- LIRGenerator::visitWasmLoadObjectField/LoadObjectFieldWithKA
/StoreObjectFieldWithKA: handle 8- and 16-bit accesses.
WasmStoreObjectRefFieldWithKA is unaffected since a ref can't be 8- or
16-bits long.
- CodeGenerator::visitWasm{Store,Load}Slot: handle 8- and 16-bit accesses.
* The actual implementations of struct.{new,set,get} and ref.cast, which are
pretty straightforward. They use the following new helper functions inside
class FunctionCompiler:
- FunctionCompiler::loadGcCanon, same function as the baseline version
- FunctionCompiler::writeValueToStructField, used for both struct.new
and struct.set.
- FunctionCompiler::readValueFromStructField, used for struct.get.
- FunctionCompiler::trapIfZero, used for ref.cast.
- FunctionCompiler::refCast, used for ref.cast.
- FunctionCompiler::field{Load,Store}InfoToMIR, used to create the right MIR
descriptions for 8- and 16-bit transactions.
It is envisaged that these helpers will be further refined in subsequent
patches to support accesses for the array instructions.
* Ridealong fix: FunctionCompiler::loadExceptionValues: add missing OOM check
for `auto* data = ..`.
Differential Revision: https://phabricator.services.mozilla.com/D161253
Add a wpt ensuring the VideoColorSpace can be constructed from all kinds
of VideoColorSpaceInit values. The new wpt is modified from an existing
mochitest and it will replace the old mochitest.
Differential Revision: https://phabricator.services.mozilla.com/D162525
When constructing a VideoFrame from the buffer data, the given
VideoColorPrimaries passed through VideoFrame's Constructor should be
set to PlanarYCbCrData's mColorPrimaries.
Depends on D161225
Differential Revision: https://phabricator.services.mozilla.com/D161226
