Skip to content
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

EffectiveViewportChangedEventArgs of EffectiveViewportChanged event differ in XAML Islands vs UWP #6423

Closed
1 of 2 tasks
lyahdav opened this issue Dec 1, 2021 · 5 comments
Closed
1 of 2 tasks

Comments

@lyahdav
Copy link

lyahdav commented Dec 1, 2021

Describe the bug

In XAML Islands when using the FrameworkElement.EffectiveViewportChanged Event, the EffectiveViewportChangedEventArgs return different results than in a UWP app.

Steps to reproduce the bug

  1. Run this solution setting the XamlIslandsApp project as Startup Project and then UwpXamlApp project: https://github.com/lyahdav/XamlPlayground/tree/scroll-viewer-visibility
  2. Scroll the ScrollViewer
  3. Look at Output pane in Visual Studio and compare results

Expected behavior

EffectiveViewportChangedEventArgs should match between XAML Islands and UWP apps.

Some differences:

  • EffectiveViewport Width/Height is always 1 in XAML Islands
  • MaxViewport Width/Height is always 1 in XAML Islands
  • When an element is fully visible or below the bottom of ScrollViewer, BringIntoViewDistanceY is incorrect in XAML Islands

Screenshots

Here's a table of the differences:
image

Here's a video comparison of one scenario that differs. UWP:

uwp.mov

XAML Islands:

islands.mov

NuGet package version

No response

Windows app type

  • UWP
  • Win32

Device form factor

Desktop

Windows version

May 2021 Update (19043)

Additional context

Possibly related issue: #3001

@ghost ghost added the needs-triage Issue needs to be triaged by the area owners label Dec 1, 2021
@StephenLPeters StephenLPeters added area-EffectiveViewport area-Islands Xaml Islands feature product-winui3 WinUI 3 issues team-Reach Issue for the Reach team labels Feb 24, 2022
@StephenLPeters
Copy link
Contributor

@marb2000 @bpulliam and @RBrid FYI

@bpulliam bpulliam removed the needs-triage Issue needs to be triaged by the area owners label Dec 6, 2022
@github-actions
Copy link

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.

@lyahdav
Copy link
Author

lyahdav commented Jul 28, 2023

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days.

This should still be relevant.

@bpulliam bpulliam added team-Controls Issue for the Controls team and removed team-Reach Issue for the Reach team labels Aug 23, 2023
@microsoft-github-policy-service microsoft-github-policy-service bot added the needs-triage Issue needs to be triaged by the area owners label Aug 23, 2023
@bpulliam bpulliam removed area-Islands Xaml Islands feature needs-triage Issue needs to be triaged by the area owners labels Aug 23, 2023
@ranjeshj
Copy link
Contributor

@lyahdav does this still repro with WinUI3 version 1.4 or 1.5 experimental ? There have been fixes in this area. The related issue you mentioned has also been fixed. Could you please verify and reopen if this still repros? Thanks!

@ranjeshj ranjeshj closed this as not planned Won't fix, can't repro, duplicate, stale Dec 13, 2023
@lyahdav
Copy link
Author

lyahdav commented Dec 15, 2023

@ranjeshj I just confirmed with WinAppSDK 1.4.3 it seems these issues are resolved.

Screenshot 2023-12-15 at 10 47 55 AM

@microsoft-github-policy-service microsoft-github-policy-service bot added the needs-triage Issue needs to be triaged by the area owners label Dec 15, 2023
@codendone codendone removed the needs-triage Issue needs to be triaged by the area owners label Sep 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants