Thanks for the feedback, it is really great to hear that your migration to .NET Core was smooth!

Is the bug above .NET Core specific? (i.e. It does not happen on .NET Framework.)

Yes, Slider control is correctly rendered in .Net Framework (from 3.5 to 4.7.2):

Thanks for confirmation @ab4d!

It is correctly rendered in .Net Framework 4.8, too.

And it is NOT correctly rendered in .Net Core 3.0 with DPI scale, either.

Here's the origin of this problem.

double viewportSize = Math.Max(0.0, ViewportSize);
 
// If viewport is NaN, compute thumb's size based on its desired size,
// otherwise compute the thumb base on the viewport and extent properties
if (double.IsNaN(viewportSize))
{
    ComputeSliderLengths(arrangeSize, isVertical, out decreaseButtonLength, out thumbLength, out increaseButtonLength);
}
else
{
    // Don't arrange if there's not enough content or the track is too small
    if (!ComputeScrollBarLengths(arrangeSize, viewportSize, isVertical, out decreaseButtonLength, out thumbLength, out increaseButtonLength))
    {
        return arrangeSize;
    }
}

Source: https://referencesource.microsoft.com/#PresentationFramework/src/Framework/System/Windows/Controls/Primitives/Track.cs,484

The ViewportSize property is always NaN when the thumb is in a Slider. However, the logic of Math.Max has been changed to match MSVC (dotnet/coreclr#20912), so viewportSize is 0 and the program goes to ComputeScrollBarLengths method. As the result, the thumb is arranged with a wrong size.

UPDATE: Replace decompiled code with the one from Reference Source.

FYI @tannergooding - fallout from some of our alignments in Math area ...

@KodamaSakuno thanks for root causing it!
Do you know where in the code it lives? Is that open source yet?

However, the logic of Math.Max has been changed to match MSVC (dotnet/coreclr#20912)

Correct. This was updated to be IEEE 754:2008 compliant and to match the behavior defined by the C/C++ language standards in Annex F - IEC 60559 floating-point arithmetic (which all of MSVC, GCC, and Clang currently follow for their implementations).

However, it is worth noting that IEEE 754:2019 (which is currently in draft form) looks to be changing this slightly. Namely, they are removing minNum/maxNum from the list of "required" operations and replacing them with new minimum/maximum and minimumNumber/maximumNumber operations which are recommended by not required and which more clearly specify various behaviors.

• minimumNumber/maximumNumber are largely compatible with the existing minNum/maxNum functions It clarifies that +0 is greater than -0 for the purpose of this function and clarifies the behavior of signalling NaN
• minimum/maximum are new and would propagate the NaN as expected here.

Once the IEEE 754 draft is officially published, there will likely be proposals going up to implement the new recommended operations; which would involve exposing the new minimum/maximum functions under System.Math/System.MathF. The names under which they would be exposed likely need more thought.

• I'll talk to some people today and determine if, for 3.0, we should revert Math.Min/Math.Max to their previous behavior (which propagates NaN) and instead expose Math.MinNum/Math.MaxNum to handle the case where the NaN should not be propagated.

@karelz I got it with a decompiler.

UPDATE: I replaced it with the one from Reference Source.

I've opened https://github.com/dotnet/corefx/issues/36925 proposing we partially revert the behavior of Math.Min/Math.Max and expose new functions for the non-propagating functionality.

Ultimately, this would mean we keep the change that considers +0 to be gerater than -0 (for the purposes of these functions only); but we continue propagating NaN so that we don't break people dependent on that behavior. We then provide new functions that don't propagate for people who need/prefer that behavior.

This should be unblocked now, once WPF can consume a new coreclr build.

Still reproduce at .NET Core SDK 3.0.100-preview4-011223 (Released 2019-04-18)
I hope fix it next .NET Core release.

@jongfeel if you follow the links, you can see that the fix is in Math in dotnet/coreclr#24039, commit dotnet/coreclr@c5b2e71. It did not get into Preview 4, but it should be part of Preview 5.

This issue has been verified fixed in Preview6. Both by the change made in coreclr and by a change in WPF to remove the dependency on Math.Max/Min NaN behavior.