This ensures we compute the NaN at runtime instead of compile time since this
is this test is aimed at JIT compatibility. In practice, these should be the
same, plus/minus the sign bit.
Differential Revision: https://phabricator.services.mozilla.com/D76344
When transitioning visibility and opacity at the same time, we create
two effects, one animating opacity, and one visibility.
We're incorrectly throttling the visibility animation due to opacity,
because _that_ effect is not animating opacity, but the other one is and
thus doesn't get throttled.
Use HasAnimationOfOpacity() to check for this case. This is slightly
sketchy, because the first time we get through there we may not even
have started the opacity animation yet. However it kinda works, because
the fact that there's a (non-throttled, because of the
aEffect.HasOpacityChange()) opacity animation means that we'll tick both
of them, and unthrottle them next frame.
This seems better than the alternative which is never throttling
animations in opacity: 0 roots.
Differential Revision: https://phabricator.services.mozilla.com/D76405
The following proposals have been merged into upstream and are no longer needed
as separate test repos:
1. nontrapping-float-to-int-conversions
2. sign-extension-ops
3. multi-value
This commit drops them to reduce test duplication, updates the pinned commits, and
re-triages the tests that are failing.
Differential Revision: https://phabricator.services.mozilla.com/D75992
This was omitted from the original upstream spec-tests that changed validation to treat
the whole module environment as pre-declaring ref.func indices, and added after our
commit landed.
Differential Revision: https://phabricator.services.mozilla.com/D75989
This commit removes the bottom type from wasm instruction validation. This type was
added in reference-types to avoid the need for lub or glb calculations for the br_table
and select instructions. Now that subtyping is removed, the typed select instruction
was kept but the bottom type was removed.
The only place where a bottom type is observable is in validation of the br_table
instruction when the input value to pass to the branches is stack polymorphic.
With a bottom-type we check that the input type is a subtype of each branch target type
referenced by br_table without fixing the input type to the branch target type. Without
a bottom-type, we do the same but fix the input type as we check branch target types.
Differential Revision: https://phabricator.services.mozilla.com/D75988
This is ugly and complicates the code some but it's manageable and allows us to keep things afloat on macOS while the testing team plugs along with the `mach` migration.
Differential Revision: https://phabricator.services.mozilla.com/D76386
- Modify the existing `test_show_hide_tab` test to right-click on a
background tab, to verify that the tab argument is the clicked tab
rather than the currently selected tab.
- Add a new test task (`test_show_hide_tab_via_tab_panel`) to serve as a
regression test for bug 1633968.
Differential Revision: https://phabricator.services.mozilla.com/D75865
For builds with ftp disabled (see below), this commit:
1) stops registering the ftp protocol handler at install time;
2) actively unregisters the ftp protocol handler at postupdate time;
3) stops unregistering the ftp protocol handler at uninstall time.
The rationale for 3) is that by the time a `helper.exe` with this
change is in place, the postupdate step has already run and
unregistered the ftp protocol handler. This could, of course, fail,
and a fallback would be nice. However having a guarded block, just
like everywhere else, will make it much more likely that the complete
removal of the ftp protocol will also cull the uninstall code. I
prefer making the latter cleanup more likely to be complete.
The bool pref that disables ftp functionality is
"network.ftp.enabled", and at this time that defaults to
!NIGHTLY_BUILD. In the {un}install process, there's no way to inspect
that pref dynamically, so we use !NIGHTLY_BUILD as well.
This opens a race window for developers to change the pref default
without changing the {un}install conditional at the same time. It
would be possible to close that window by introducing a new configure
subst but given the imminent removal of the ftp protocol entirely it
doesn't seem necessary.
Differential Revision: https://phabricator.services.mozilla.com/D74503
Comparing to .webp, we already do two of three things needed. This
arranges the last thing: registering the file association.
Differential Revision: https://phabricator.services.mozilla.com/D76244
