umbraco / Umbraco-CMS

Umbraco is a free and open source .NET content management system helping you deliver delightful digital experiences.
https://umbraco.com
MIT License
4.49k stars 2.69k forks source link

A Non Variant Content Picker, will still open up the picking dialog on a greyed out variant, when clicking the 'label' #9783

Closed marcemarc closed 2 years ago

marcemarc commented 3 years ago

I have a content picker property on a Document Type that is allowed to vary by language

The content picker itself, isn't allowed to vary by content

So items can only be picked on the default language.

When an editor views the variant, the picked items are greyed out as expected, and the 'Add' button cannot be clicked...

... however if the editor clicks the 'label' for the property editor, it does actually trigger the opening up of the dialog to pick items...

image

animated explanation:

variantcontentpicker

Umbraco version

8.10.1

Reproduction

In an umbraco site with mulitple languages

Create a Document Type that can vary by content

Create a Content Picker Property that picks content and does not vary by content.

Pick the items on the Default language, switch to a language variant, the picked items should be greyed out - click on the label for the greyed out property editor, you'll see the option to pick content - when you shouldn't!

Expected result

I'd expect clicking on the label would change the mouse pointer to be a no entry sign, and no dialog should be displayed for picking content

Actual result

Editors feel like they can pick content here for their variant - but that is not the case, we do not want to allow editors to pick content.

emma-hq commented 3 years ago

Hello Marc,

Good day to you 😄 I'll take a look, reproduce and comment or label accordingly.

Emma

emma-hq commented 3 years ago

Hey @marcemarc,

Yep! This is a bug and it's possible to reproduce this in the latest release, 8.11.1. I will pop an up-for-grabs label on it as you've given us plenty to work with here.

Emma

umbrabot commented 3 years ago

Hi @marcemarc,

We're writing to let you know that we would love some help with this issue. We feel that this issue is ideal to flag for a community member to work on it. Once flagged here, folk looking for issues to work on will know to look at yours. Of course, please feel free work on this yourself ;-). If there are any changes to this status, we'll be sure to let you know.

For more information about issues and states, have a look at this blog post

Thanks muchly, from your friendly Umbraco GitHub bot :-)

bjarnef commented 3 years ago

This seems to be similar to the issue I reported here using a simple toggle, but a general issue because we have for attribute on property label while the editor has id attribute using property alias. We should probably cover the label with an overlay or/and prevent the the click event om the label. https://github.com/umbraco/Umbraco-CMS/issues/9676

marcemarc commented 3 years ago

Yes, the label extends the target for the form control it is linked to by the 'for' attribute.

So a click on the label = a click on the button.

The trickyness i think is the property editor doesn't appreciate it's in a disabled state... Which makes it difficult to check this state when the label triggers the ng-click event of the button..

The other thought is does the 'add' button need to have the id of the property alias? Eg if the whole editor had a wrapping element with id matching the property alias and the add button had id: btn-{{editor. alias}}... That would stop the label triggering ng-click (i think) - but in a non variant scenario would it make it less accessible? eg would clicking the label pass focus to the editor sufficiently? - or should the label be somehow rendered differently in this situation?

umbrabot commented 2 years ago

Hiya @marcemarc,

Just wanted to let you know that we noticed that this issue got a bit stale and might not be relevant any more.

We will close this issue for now but we're happy to open it up again if you think it's still relevant (for example: it's a feature request that's not yet implemented, or it's a bug that's not yet been fixed).

To open it this issue up again, you can write @umbrabot still relevant in a new comment as the first line. It would be super helpful for us if on the next line you could let us know why you think it's still relevant.

For example:

@umbrabot still relevant This bug can still be reproduced in version x.y.z

This will reopen the issue in the next few hours.

Thanks, from your friendly Umbraco GitHub bot :robot: :slightly_smiling_face: