When a flex item's subtree is dirty, we should reject the cached
measurement and perform a measuring reflow for the item to get the
correct ascent. Without this patch, we are going to call
FlexItem::ResolvedAscent() in the flex algorithm based on a dirty flex
item subtree, and get a wrong ascent. (Although we'll still perform the
final reflow for the item, it's too late to get the correct ascent to
compute flex container's ascent.)
With the above modification, it exposes an existing issue that
layout/generic/crashtests/1666592.html can now trigger
`MOZ_ASSERT(!mFinalReflowSize)` in UpdateFinalReflowSize() in
fragmentation scenario. The problem is: when we clone a FlexItem for a
child frame in a flex container's continuation via FlexItem::CloneFor(),
we didn't reset the mHadMeasuringReflow flag, so we wrongly assume it
had a measuring reflow and may update its final reflow size based on the
cached metrics. However, we never run measuring reflow for flex items in
flex container's continuation, so we should reset the flag to prevent it
from falling into wrong path in FlexItem::NeedsFinalReflow().
Differential Revision: https://phabricator.services.mozilla.com/D121405
The interesting wrinkle here are the `MSIX(*-multi)` repackaging
tasks, which depend on (signed) langpacks. Said langpacks are
cross-platform and are produced on linux64 at this time.
Differential Revision: https://phabricator.services.mozilla.com/D119670
This is strictly a convenience for local developer testing. In
automation, we'll use the regular signing process via `autograph`,
etc.
Differential Revision: https://phabricator.services.mozilla.com/D116181
All files were generated by the "Visual Assets" panel in Visual
Studio. The file names are the Visual Studio default names. The
densities are a subset of the Visual Studio "Suggested" densities:
arbitrarily, I kept the -200 and dropped the -100 and -400
resolutions, and I kept the -256 and dropped the -16 and -48 target
sizes. We expect Windows to scale these appropriately, and we can
always adjust if we want higher resolutions in the future.
For MSIX, we will release Firefox Beta with a different package name.
We would prefer to brand Firefox Beta differently than Firefox
(Release), and at one point I included assets generated from the Beta
`Fx-Browser-Beta-icon-fullColor-512.png` file included in the Beta
Assets ZIP archive from https://mozilla.design/firefox/logos-usage/.
However, to simplify, I've removed these and made --channel=beta use
the same branding as --channel=release. This is consistent with the
general Desktop release process.
For the other release channels, assets were generated from
`content/about-logo@2x.png`, which is the highest resolution (384x384)
source I can find. These PNGs look better than those from
https://mozilla.design/firefox/logos-usage/ (to me): I theorize that
this is because they have already been quantized to 8bit colour and
that this avoids colour artifacts near edges.
Differential Revision: https://phabricator.services.mozilla.com/D116179
When mfplat.dll loads msvp9dec_store.dll, it posts a task
to unload the module to the work queue even if msvp9dec_store.dll
is already loaded and mfplat.dll skips LoadLibrary. Therefore,
we cannot safely lock msvp9dec_store.dll by loading it as data.
The proposed fix is to skip processing the module.
Differential Revision: https://phabricator.services.mozilla.com/D121777
We support the setter of Animation.timeline, so it's possible to have a
null |mTimeline| when calculating the start value for off-main-thread
animations. If it's null, it must be different from the document
timeline, so in this case we don't set |mReplacedTransition|.
So let's move the assertion below the if-check of |mReplacedTransition|.
Differential Revision: https://phabricator.services.mozilla.com/D121675
The effect of this bug should be a slow leak of unreferenced cache entries
between sessions. After the fix we should just be appropriately cleaning them
up.
Differential Revision: https://phabricator.services.mozilla.com/D121644
The waitForShutdownDecoder test helper function was introduced in bug 1521964,
but the interface for the function that it was calling (mozDebugReaderData)
changed in bug 1542674. Due to the way the promiseWaitForCondition used to
work before bug 1721898, the sudden breakage of that interface was silently
ignored and this helper function stopped working without us knowing.
After bug 1721898 landed, this breakage suddenly became visible. This patch
updates waitForShutdownDecoder to use the machine-readable debug data
structure that was introduced in bug 1542674. It's still a hacky way of
determining when a video decoder has shut down, but I'm not aware of
any other way of doing that, and this is just for a test.
Differential Revision: https://phabricator.services.mozilla.com/D121766
Needed to tweak tests a bit because the code is now more descerning
wheter to fire an event or not. Will do so only if the state actually
changes.
Depends on D120901
Differential Revision: https://phabricator.services.mozilla.com/D120902
Also folded ARIAAttributeChanged into DOMAttributeChanged temporarily.
Will streamline that further in the next patch where state changes are
done a bit better.
Depends on D120900
Differential Revision: https://phabricator.services.mozilla.com/D120901
We do so as a side effect of using system_lib_option for all *-system-*
options for old-configure, all but one of which are for system
libraries.
Differential Revision: https://phabricator.services.mozilla.com/D121690
about:newtab doesn't load aboutPrivateBrowsing.ftl and conversely about:privatebrowsing doesn't load newtab.ftl. Since permanent private browsing mode uses about:newtab as its new tab, we need to make sure we load our strings from newtab.ftl in that case.
Differential Revision: https://phabricator.services.mozilla.com/D121646