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

XWIKI-20996: AWM entry edit forms don't have labels. #3584

Open
wants to merge 23 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 13 commits
Commits
Show all changes
23 commits
Select commit Hold shift + click to select a range
6eff29e
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Nov 28, 2023
14d4148
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Nov 29, 2023
4b7fe5c
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Dec 1, 2023
b06e52a
Merge branch 'xwiki:master' into XWIKI-20996
Sereza7 Jul 1, 2024
85773a0
Merge branch 'xwiki:master' into XWIKI-20996
Sereza7 Oct 22, 2024
6477c85
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Oct 22, 2024
00583b6
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Oct 22, 2024
e565116
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Nov 19, 2024
71292c4
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Nov 19, 2024
9e02c72
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Nov 19, 2024
5c7cd93
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Nov 19, 2024
b6a9fb9
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Nov 19, 2024
2e76e37
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Nov 19, 2024
e805384
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Nov 26, 2024
7cb96fc
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Nov 26, 2024
c9a33a3
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Nov 26, 2024
6a45848
Merge branch 'xwiki:master' into XWIKI-20996
Sereza7 Dec 17, 2024
f0a99b8
XWIKI-20996: AWM entry edit forms don't have labels
Sereza7 Dec 17, 2024
23d77a5
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Dec 17, 2024
2ee99f1
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Jan 15, 2025
c030a53
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Jan 15, 2025
be46a71
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Jan 15, 2025
a1d296b
XWIKI-20996: AWM entry edit forms don't have labels.
Sereza7 Jan 16, 2025
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -314,6 +314,7 @@ xcontext.put('propertyCustomDisplayer', new PropertyCustomDisplayer(xcontext))
* Displays a configuration property of a class field. This macro can also be used to display a property of an object.
*#
#macro (displayFieldProperty $property $prefix $field)
## This 'displayFormType' property only exists for boolean fields.
#set ($displayFormType = $property.getProperty('displayFormType'))
#if ($property.classType == 'Boolean' && (!$displayFormType || $displayFormType.value == 'checkbox'))
<dt>
Expand Down Expand Up @@ -1392,8 +1393,10 @@ XWiki.FormFieldPrettyNameManager = Class.create({
var label = previousDT.down('label');
prettyNameInput.title = label.textContent || label.innerText;
}
prettyNameInput.ariaLabel = '$escapetool.javascript($services.localization.render('platform.appwithinminutes.classEditorFieldPrettyNameToolTip'))';
// Replace the preview label with the pretty name input.
var previewLabel = field.getViewer().down('label');
// We unset the for attribute, so that this label will not be set implicitely OR explicitely anymore.
previewLabel.writeAttribute('for', '');
previewLabel.removeChild(previewLabel.lastChild);
previewLabel.insert(prettyNameInput);
Expand All @@ -1418,10 +1421,12 @@ XWiki.FormFieldDefaultValueManager = Class.create({
_enhanceFieldDefaultValue : function(event) {
var field = event.memo.field;
var fieldName = field.getName();
field.getViewer().select('input[type=text]', 'textarea').each(function(input) {
// We select the default field input and update it.
field.getViewer().select('dd :input').each(function(input) {
if (!input.title && input.name.endsWith('_0_' + fieldName)) {
input.title = '$escapetool.javascript($services.localization.render('platform.appwithinminutes.classEditorFieldDefaultValueToolTip'))';
}
input.ariaLabel = '$escapetool.javascript($services.localization.render('platform.appwithinminutes.classEditorFieldDefaultValueToolTip'))';
});
},
_onSave : function() {
Expand Down Expand Up @@ -1456,7 +1461,8 @@ XWiki.FormFieldHintManager = Class.create({
if (hintInput) {
hintInput.addClassName('xHint');
if (!hintInput.title) {
hintInput.title = 'Hint';
hintInput.title = '$escapetool.javascript($services.localization.render('platform.appwithinminutes.classEditorFieldHintToolTip'))';
hintInput.ariaLabel = '$escapetool.javascript($services.localization.render('platform.appwithinminutes.classEditorFieldHintToolTip'))';
}
// Move the hint input below the pretty name input, in the field viewer.
var dd = hintInput.up('dd');
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -53,8 +53,7 @@
#set ($useWysiwygEditor = $xwiki.getUserPreference('editor') == 'Wysiwyg')
#end
{{html clean="false"}}
## The "content" id is expected by some JavaScript and CSS code.
#set ($id = 'content')
Comment on lines -54 to -55
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an example of JavaScript code that looks for a text area with content id https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-web/xwiki-platform-web-war/src/main/webapp/resources/js/xwiki/wikieditor/wikibits.js#L57 . Have you checked that the "wiki editor" toolbar is properly loaded for the Content AWM field when the user prefers the text editor (rather than the WYSIWYG editor)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After looking for a while to see what I did wrong, it seems like this PR doesn't especially break this. As of now, the wiki editor toolbar with inline AWM field edition is broken ( it replaces the whole HTML )...

I just pushed a small fix in c030a53 that should make things okay once the regression is handled

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2025-01-15.18-08-19.mp4

This regression has been in XWiki standard for more than a few months ^^'
I just tested XWiki 14.10.22 and it's already there (see video above)

#set ($id = "${prefix}${name}1")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really the correct ID? Shouldn't this number be based on some variable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I thought that the content and title fields were unique.
It turns out we don't prevent this when the user edits the app. I'm not sure what are the repercussion on the results, but if one provides multiple fields for those, there will be an issue with labelling 👍

Looking for a way to access this variable. AFAIR it's not straightforward and will probably require a hackish solution.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, it's just stored in the $name variable we get from the context in which those templates are used.
I could find this thanks to displayer_date.vm which is not defined the same way as those two templates, but has a similar role.
Note that in both of those templates, the value $name is overridden, we want to compute with the info from the context so we have to compute the ID at the start of the template.

I just used #set ($id = $escapetool.xml("${prefix}${name}")) on both and we're good :)
This works both on classEdition and entryEdition.

#if (!$useWysiwygEditor)
<div id="xwikieditcontentinner">
## The tool bar may have an entry to insert an HTML macro. Make sure it doesn't break the HTML macro we are currently in.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -45,14 +45,14 @@
#set ($value = $xwiki.getDocument("$stringtool.removeEnd($className, 'Class')Template").title)
#else
## We are editing an application entry so the title must be read from / written to the current document.
#set ($name = 'title')
#set ($name = 'title1')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change looks wrong/would need some motivation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment and similar resolution as #3584 (comment)

#set ($value = $tdoc.title)
#if ("$!value" == '')
#set ($value = $tdoc.documentReference.name)
#end
#end
{{html clean="false"}}
<input type="text" name="$name" value="$!escapetool.xml($value)"
<input id="${prefix}$name" type="text" name="$name" value="$!escapetool.xml($value)"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is missing escaping.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to escape all variables declared locally? This $name, just like the $prefix, is defined a few lines above and I didn't think it was necessary to escape it.
I added escaping on the name in e805384 nevertheless 👍

## The default value for an AppWithinMinutes field should be optional so we make only the actual page title
## mandatory and not the template title, which holds the default title value.
#if ($name == 'title' && $xwiki.getSpacePreference('xwiki.title.mandatory') == 1)required #end
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -135,6 +135,8 @@ platform.appwithinminutes.classEditorMoveFieldLabel=Move
platform.appwithinminutes.classEditorMoveFieldHint=Drag and drop to change the order

platform.appwithinminutes.classEditorFieldDefaultValueToolTip=Default value
platform.appwithinminutes.classEditorFieldPrettyNameToolTip=Pretty Name
platform.appwithinminutes.classEditorFieldHintToolTip=Hint

### Date Picker
platform.appwithinminutes.classEditorDatePickerAcceptSelectedDate=OK
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -88,10 +88,6 @@
margin-bottom: 0;
}

textarea#content {
width: 100%;
michitux marked this conversation as resolved.
Show resolved Hide resolved
}

//
// Editable properties (in-place editing)
//
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -130,7 +130,17 @@ define('editableProperty', ['jquery', 'xwiki-meta'], function($, xcontext) {
// Allow others to enhance the editor.
$(document).trigger('xwiki:dom:updated', {'elements': editor.toArray()});
// Focus the first visible input.
editor.find(':input').filter(':visible').focus();
var editInput = editor.find(':input').filter(':visible');
// If we cannot find any kind of editInput, then we're in a weird edge case
// and we don't want to apply any of the following changes.
if(!editInput) { return; }
Sereza7 marked this conversation as resolved.
Show resolved Hide resolved
editInput.focus();
// Make sure the edit input has an ID, and use the name of the input as a fallback
if (!editInput.attr('id')) {
editInput.attr('id', editInput.attr('name'));
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not convinced by this. The value of the name attribute can be (and often is) very generic which means it's not a good id because it can conflict with other ids on the page. I'd rather default to a random id, that can have the name as prefix.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a UUID to this id attribute in be46a71 . I don't like using random to set something as an ID (might introduce hard to reproduce inconsistencies/bugs), but as far as I understand, we don't really have a choice if we want to be sure that the id is unique here.

For the sake of testing, I reverted the unique ID we provide for the Content textarea on my local instance, and here is the result of the changes. It looks okay to me.

Screenshot from 2025-01-15 17-54-36

// Bind the label to the newly generated edit input
Sereza7 marked this conversation as resolved.
Show resolved Hide resolved
editableProperty.find('label').attr('for',editInput.attr('id'));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this whole code be wrapped in an if-statement if there is an editInput?

Also, this change seems to be much more general than AWM. I'm not saying it's bad, I'm just saying that it is more general.

Shouldn't there be code to remove the for attribute again from the label when editing is finished?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this whole code be wrapped in an if-statement if there is an editInput?

Since this only happens when the promise to retrieve the edit display of a field is achieved, I didn't expect this to happen. I added a condition to finish the function early and skip those changes though, better safe than sorry 👍

Also, this change seems to be much more general than AWM. I'm not saying it's bad, I'm just saying that it is more general.

Yup, I was navigating through multiple kinds of UI for objects and there was an issue with AWM inline edition. I tracked the cause and ended up changing things here.

Shouldn't there be code to remove the for attribute again from the label when editing is finished?

Technically it doesn't hurt to leave it. However it's better for HTML clarity to clean up the attribute when it's not useful anymore. Added a couple lines to clean this up on saving or canceling the edition

Sereza7 marked this conversation as resolved.
Show resolved Hide resolved
}).catch(() => {
new XWiki.widgets.Notification(l10n['web.editableProperty.editFailed'], 'error');
return Promise.reject();
Expand All @@ -148,11 +158,15 @@ define('editableProperty', ['jquery', 'xwiki-meta'], function($, xcontext) {
.next('.editableProperty-editor').filter(':visible').trigger('xwiki:actions:cancel').hide();
editableProperty.find('.editableProperty-save, .editableProperty-cancel').hide();
editableProperty.find('.editableProperty-edit').show();
// Remove the for attribute from the label, resetting it to its default state
Sereza7 marked this conversation as resolved.
Show resolved Hide resolved
editableProperty.find('label').removeAttr('for');
};

var save = function(editableProperty) {
// Disable the save and cancel actions while the property is being saved.
editableProperty.find('.editableProperty-save, .editableProperty-cancel').addClass('disabled');
// Remove the for attribute from the label, resetting it to its default state
Sereza7 marked this conversation as resolved.
Show resolved Hide resolved
editableProperty.find('label').removeAttr('for');
// Show progress notification message.
var notification = new XWiki.widgets.Notification(l10n['core.editors.saveandcontinue.notification.inprogress'],
'inprogress');
Expand Down