New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BaseCompatibilityPreferences.ReuseDispatcherSynchronizationContextInstance has wrong default value #245

Open
ericstj opened this Issue Jan 8, 2019 · 3 comments

Comments

Projects
None yet
2 participants
@ericstj
Copy link
Member

ericstj commented Jan 8, 2019

  • WPF Version: 3.0.0-alpha-27122-4
  • Windows version: Win 10 1809 (17763.195)
  • Does the bug reproduce also in WPF for .NET Framework 4.8?: No

Problem description:
BaseCompatibilityPreferences.ReuseDispatcherSynchronizationContextInstance is defaulting to true on .NETCore but defaults to false on .NET 4.5 and later.

Actual behavior:
BaseCompatibilityPreferences.ReuseDispatcherSynchronizationContextInstance is true.

Expected behavior:
BaseCompatibilityPreferences.ReuseDispatcherSynchronizationContextInstance is false.

Minimal repro:
Start an app and examine value of BaseCompatibilityPreferences.ReuseDispatcherSynchronizationContextInstance

Customer issue: dotnet/corefx#33612.

@vatsan-madhavan

This comment has been minimized.

Copy link
Member

vatsan-madhavan commented Jan 8, 2019

Getting AppContext and [*]CompatibilityPreferences defaults to instantiate correctly is something we are yet to get to. These need to be done to get many important scenarios to work correctly (or work at all) - for e.g., high DPI behavior. This is in our queue as an important work item for the near future.

@vatsan-madhavan vatsan-madhavan added the bug label Jan 8, 2019

@vatsan-madhavan vatsan-madhavan added this to the Preview milestone Jan 8, 2019

@ericstj

This comment has been minimized.

Copy link
Member

ericstj commented Jan 8, 2019

@vatsan-madhavan this was simply a case of the defaults being wrong in the port. One of the flags was inverted so that instead of getting "latest" behavior, one flag was defaulted to "old" behavior. I submitted a fix internally so that the port would be consistent with "latest" behavior.

@ericstj

This comment has been minimized.

Copy link
Member

ericstj commented Jan 8, 2019

Bug is fixed internally with 416d18d4d2ff20531f758fd99ab540e950dd24d8. Will close this once that makes it into the SDK.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment