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

[Bug, iOS] Frame shadow layer not properly removed #8567

Closed
jfversluis opened this issue Nov 19, 2019 · 3 comments
Closed

[Bug, iOS] Frame shadow layer not properly removed #8567

jfversluis opened this issue Nov 19, 2019 · 3 comments

Comments

@jfversluis
Copy link
Member

Description

By the merge of #7518 there is now a bug where Frames aren't properly removed. At leased when used in a BindableLayout with the shadow on. This is discovered while reviewing the empty view implementation on the BindableLayout.

Investigation

I have tried to fix it, but can't quite get it right. When you add a Dispose to the FrameRenderer on iOS like this:

                protected override void Dispose(bool disposing)
		{
			if (_isDisposed)
				return;

			if (disposing && _shadowView != null)
			{
				_shadowView.RemoveFromSuperview();
				_shadowView.Dispose();
				_shadowView = null;
			}

			_isDisposed = true;
			
			base.Dispose(disposing);
		}

It seems a bit better, but not entirely fixed. See below on what that does to the behavior.

Untitled

Notice how the first item is removed and the shadow disappears, but there still remains an artefact at the bottom. It almost seems like the boxes are removed in the opposite direction.

Steps to Reproduce

  1. Start Gallery app
  2. Go to BindableLayout Gallery - Legacy
    2 a. If the empty view PR (Implemented BindableLayout EmptyView #7686) got merged in the meantime, remove the HasShadow="false" from the Frame on this page
  3. Remove an item and observe that an empty yellow box stays behind

Expected Behavior

Frame is entirely removed from the layout, no empty yellow box is shown

Actual Behavior

The frame outline (yellow box) is still visible as an artefact on the screen

Basic Information

Screenshots

Broken

@jfversluis jfversluis added t/bug 🐛 p/iOS 🍎 i/regression s/unverified New report that has yet to be verified labels Nov 19, 2019
@pauldipietro pauldipietro added this to New in Triage Nov 19, 2019
@jfversluis jfversluis added e/3 🕒 3 excellent-report and removed s/unverified New report that has yet to be verified labels Nov 25, 2019
@jfversluis
Copy link
Member Author

I totally see this happening, thank you for your excellent report @jfversluis!

@jfversluis jfversluis moved this from New to Ready For Work in Triage Nov 25, 2019
@samhouts samhouts added this to To do in iOS Ready For Work Nov 26, 2019
@samhouts samhouts removed this from Ready For Work in Triage Nov 26, 2019
@samhouts samhouts added this to the 4.5.0 milestone Mar 19, 2020
@samhouts samhouts added this to Backlog in Shell via automation Mar 19, 2020
@samhouts samhouts added this to To do in Sprint 167 via automation Mar 19, 2020
@samhouts samhouts removed this from Backlog in Shell Mar 19, 2020
@samhouts samhouts added this to To do in v4.5.0 Mar 19, 2020
@samhouts samhouts added this to To do in Sprint 168 via automation Mar 23, 2020
@samhouts samhouts moved this from To do to Continued in next sprint in Sprint 167 Mar 23, 2020
@samhouts samhouts moved this from To do to Continued in next sprint in Sprint 168 Apr 23, 2020
@samhouts samhouts added the 4.5.0 regression on 4.5.0 label Jun 17, 2020
@samhouts
Copy link
Member

@jfversluis Did you happen to fix this, by any chance? 😁

@jfversluis
Copy link
Member Author

jfversluis commented Jun 17, 2020

Well waddayaknow! I did! Assuming that the Frame fixes were merged and in master currently. Retested it and didn't see this problem anymore.

Also checked 4.5, not happening there anymore either

iOS Ready For Work automation moved this from To do to Done Jun 17, 2020
@samhouts samhouts removed this from Done in iOS Ready For Work Jul 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
No open projects
Sprint 167
  
Continued in next sprint
Sprint 168
  
Continued in next sprint
v4.5.0
  
To do
Development

No branches or pull requests

2 participants