Xamarin.forms: Controls Don't Disable Properly

[AceCoderLaura]

Description

Controls do not visually indicate that they are disabled and they are not disabled according to the platform.

Steps to Reproduce

1. Checkout https://bitbucket.org/ChristianFindlay/xamarin-forms-scratch
2. Open the TestXamarinForms.sln file
3. Run the application
4. Click on "IsEnabled Issue"
5. Notice the enabled controls on screen, appearing as enabled controls should
6. Click the "Disable This Page" button
7. Notice none of the controls have had their native "IsEnabled" property set to false
8. Notice that none of the controls exhibit visual indications of being disabled
9. Notice that not even the page is greyed out to any degree

Expected Behavior

The controls should grey out by having the native IsEnabled property set on them.

Actual Behavior

The page becomes what seems to be input transparent, which is not the same as disabled.

Basic Information

• Version with issue: 2.5.0.280555
• Last known good version: Unknown
• IDE: Visual Studio 2017 Professional
• Platform Target Frameworks:
  
  
  
  • Android: 8.0
  
  
  • UWP: 16299
  
  
• Nuget Packages:
  Google.Apis.Calendar.v3 {1.32.2.1146} TestXamarinFormsLibrary
  NETStandard.Library {2.0.1} TestXamarinFormsLibrary
  Xamarin.Forms {2.5.0.280555} TestXamarinFormsLibrary
  Xamarin.Forms {2.5.0.280555} TestXamarinForms.iOS
  Xamarin.Forms {2.5.0.280555} TestXamarinForms.Droid
  Microsoft.NETCore.UniversalWindo... {6.0.7} TestXamarinForms.UWP
  Xamarin.Forms {2.5.0.280555} TestXamarinForms.UWP
• Affected Devices: HTC U11

Screenshots

Reproduction Link

https://bitbucket.org/ChristianFindlay/xamarin-forms-scratch

[jassmith]

Disabling a parent does not automatically disable all children.

[MelbourneDeveloper]

@jassmith , disabling a parent clearly _does_ automatically make all children have input disabled. If you'd bothered to open the sample you would have noticed this. This was a bug that was recently fixed in Xamarin Forms.

Secondly, the issue is very clear if you had read @AceCoderLaura's steps for reproduction. The issue is that although all the controls on screen will not accept input, they are not actually disabled at the native platform level, and do not follow the native platform's disabled behaviour. If you open the sample and look at the behavior you can see that none of the controls accept input, but their is no visual indication to the user that the controls are disabled. That's because they're not disabled at the native level. They just have their input blocked.

The easiest way to see this in UWP.

This is a critical issue. If users can't tell when a control is disabled, we will get nothing but complaints.

[MelbourneDeveloper]

@jassmith please reopen this issue.

[jassmith]

I am aware of the change, we do not flow through the disabled state to children element. I will at your request re-evaluate that behavior.

[MelbourneDeveloper]

@jassmith if you "do not flow through the disabled state to children element", why are all the controls on the screen disallowing input? Have you even looked at the sample?

[jassmith]

I have yes, its running on my phone right now. What I am saying is the IsEnabled property doesn't flow down like BindingContext does, for example. Now when the layout gets disabled it stops allowing hit tests to hit it, which also effectively disables hit testing for its children.

I will get into the details of exactly whats going on here in a moment but I am checking older versions first to make sure I don't misspeak. The behavior you are seeing however is as I recall already how it worked on iOS and we simply applied consistent behavior to Android/UWP. Thats from memory however.

Flowing the IsEnabled property down however would be a huge change that I would love to do but can't. The choice of which way to move the proper behavior was mostly motivated by the fact that it was much easier to make the other platforms conform with iOS than the other way around.

If you want your controls to appear disabled you must actually set IsEnabled = false; on them.

[MelbourneDeveloper]

@jassmith if this is the case, why is there half a feature implemented?

When you turn of IsEnabled at the highest level, lower level controls mostly stop accepting input. Why is that even being done in Xamarin Forms? It's basically useless. We expected it to work, because the feature is half implemented, but when we looked more closely, it's just bizarre behavior.

Do you realize that you can even tab in to controls where the parent has IsEnabled set to false? What's the point of the children not accepting input, if the user can get around this?

My recommendation would be to cascade the IsEnabled property down to other controls as per other XAML based Microsoft technologies. But, if that is not possible, there shouldn't be any inconsistent behavior that makes developers think that the controls are disabled when they are actually not.

[jassmith]

As I said, I would love to change the behavior but I can't. And yes I realize you can do those things you mention.

[MelbourneDeveloper]

@jassmith , why can't you do it?

If you don't do it, we will have to. So, what problems are we going to face?

[jassmith]

Changing the default behavior would be considered a breaking change, and yes I know we've had this discussion before. I would actually love to change the behavior of this interaction to something I consider far saner. You're 100% right that this could be made better by having an implicit flowthrough of the IsEnabled property. This however would be a behavioral break that would have to be quirked out.

I am not saying quirking it on its own is a blocker to us doing it, but it certainly adds a huge amount of complexity and delay to it actually getting done. In the past we've been allowed to unify behaviors, but not change behaviors once they are unified (and no existing backend did flowthrough for us to unify towards).

[MelbourneDeveloper]

Well, what are we supposed to do?

[jassmith]

I already passed this over to the PM team, that's it. If you want to write a spec you can but it will need to include some kind of sane quirking mechanism that doesn't currently exist in forms (that will be the bulk of the delay).

[jassmith]

Oh as for you,

        private void EnableElementAndChildren (VisualElement element, bool enable)
        {
            element.IsEnabled = enable;
            if (element is ILayout)
            {
                foreach (var child in element.LogicalChildren)
                    EnableElementAndChildren(element, enable);
            }
        }

I suppose the ILayout check isn't really needed, but I like it just to avoid going into weird edge cases.

[MelbourneDeveloper]

OK. Thanks. This isn't going to deal with all situations. We are going to need to do something like keep a list of all elements that were previously disabled, and then re disable them when other controls are re enabled. Of course this breaks all kinds of logic like binding logic and so on.

Meantime, I recommend coming up with a long term plan on how to fix this issue, and also rip out the hack code to make the controls input disabled when their parent is disabled. This hack doesn't fix any issues. It just confused us and made us think IsEnabled cascading was working when it actually wasn't.

[jassmith]

You could without much difficulty implement an effect to achieve this in a more elegant fashion. When I'm not feeling so stuck between a rock and a hard place on this issue I will take some time to try to hack it together for you. Basically it would be entirely possible to write an effect that cascades down the IsEnabled'ness of a VisualElement

[AceCoderLaura]

We're aware of our options in terms of hacks. There's no need to bother with such folly. Please focus on what you can do instead of what we're going to have to do. Thank you.

[jassmith]

okie dokie, I'll leave that to you then.

[KthProg]

Soooooooo?

[KthProg]

I noticed that I disabled a cell in a list view and there was no visual indication of it being disabled. This issue is over a year old.

[viktorszekeress]

I don't understand why this even needs a discussion. In all platforms that use XAML (WPF, WP8, UWP), it's a well know fact, that IsEnabled does apply to all children.
Hence this should not be considered as behavior change, it should be considered as bug fix. I consider current implementation as wrong (and so do all other developers, just look at xamarin forums).

[derekantrican]

Related issue: https://github.com/xamarin/Xamarin.Forms-api-docs/issues/97