Skip to content
This repository has been archived by the owner on May 1, 2024. It is now read-only.

Headless Layouts are causing crashing and graphics glitches in Cells #4168

Open
seansparkman opened this issue Oct 22, 2018 · 2 comments
Open
Labels
a/layout e/6 🕕 6 help wanted We welcome community contributions to any issue, but these might be a good place to start! i/high Completely doesn't work, crashes, or is unusably slow, has no obvious workaround; occurs less often p/Android up-for-grabs We welcome community contributions to any issue, but these might be a good place to start!

Comments

@seansparkman
Copy link

seansparkman commented Oct 22, 2018

Description

When I use a headless layout inside of a cell, it would cause a graphical glitch where the data that was previously in the cell would show up under or on top of the new data in the cell. This became a jumbled mess.

When I used more labels and an FFImageLoading CachedImage, it would just crash the app with the below exception.
I should probably test this in iOS as well.

Removing the CompressedLayout.IsHeadless="True" fixes both problems.

Steps to Reproduce

  1. Create Custom ViewCell
  2. Use StackLayouts
  3. Add a label with bound data to the StackLayout
  4. Assign CompressedLayout.IsHeadless="True" to the StackLayout

Expected Behavior

For the application not to crash and display bound data in the cell.

Actual Behavior

When using ffimageloading cached images and formatted string, the application crashes with this exception:

Unhandled Exception:

System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index occurred

When using just a basic label by itself, the previous use label used in that cell would appear over the new data in the label. It became a jumbled messed.

Basic Information

  • Version with issue: 3.3.0.912540
  • Last known good version:
  • IDE: Visual Studio 2017 15.8.7
  • Platform Target Frameworks:
    • iOS:
    • Android: 8.1 Oreo
    • UWP:
  • Android Support Library Version:
  • Nuget Packages: Xamarin.FFImageLoading.Forms 2.4.3.840
  • Affected Devices: Emulator

Screenshots

https://1drv.ms/u/s!AgoxySKwbTmmpq1aJioVGraINndXNA

Reproduction Link

https://gist.github.com/seansparkman/560624cba6608eaa25831e59fcee7c71

@StephaneDelcroix StephaneDelcroix added p/Android a/layout i/low Has trivial workaround; affects very few users e/6 🕕 6 labels Oct 24, 2018
@samhouts samhouts added the i/high Completely doesn't work, crashes, or is unusably slow, has no obvious workaround; occurs less often label May 29, 2019
@samhouts samhouts added inactive Issue is older than 6 months and needs to be retested help wanted We welcome community contributions to any issue, but these might be a good place to start! up-for-grabs We welcome community contributions to any issue, but these might be a good place to start! labels Jul 4, 2019
@Happypig375
Copy link
Contributor

Lol. How can an issue be labeled both high-impact and low-impact? Clearly some management issues are going on.

@seansparkman
Copy link
Author

It's also been set to Android Ready For Work and Inactive.

@samhouts samhouts removed i/low Has trivial workaround; affects very few users inactive Issue is older than 6 months and needs to be retested labels Jun 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
a/layout e/6 🕕 6 help wanted We welcome community contributions to any issue, but these might be a good place to start! i/high Completely doesn't work, crashes, or is unusably slow, has no obvious workaround; occurs less often p/Android up-for-grabs We welcome community contributions to any issue, but these might be a good place to start!
Projects
None yet
Development

No branches or pull requests

4 participants