HARVESTER: Fix Harvester image issues

[n313893254]

Summary

Fixes Harvester image issues

Occurred changes and/or fixed issues

• [BUG] Image's labels will not be copied when execute Clone harvester/harvester#2562
• [BUG] harvesterhci.io.virtualmachineimage spec.displayName displays differently in single view of image harvester/harvester#2563
• [BUG] Press the Enter key, the page will be refreshed automatically harvester/harvester#2569

Technical notes summary

• Fix clone image lack of labels
• Fix image can save the invalid name
• Fix some settings that the input is focused and then press enter keyboard will refresh the page. This should be the implicit behavior： https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#implicit-submission

Areas or cases that should be tested

Areas which could experience regressions

Screenshot/Video

[mantis-toboggan-md]

We should try to solve this in a more general way so we don't accidentally cause this bug on other pages in the future. We can just put @submit.prevent on the form element here: https://github.com/rancher/dashboard/blob/master/shell/components/CruResource.vue#L344

This only happens with <form> that have only one input element, so I do not expect this change to cause problems elsewhere. https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#implicit-submission

[n313893254]

Done, added the @submit.prevent for CruResource form.

[n313893254]

@mantis-toboggan-md Thanks for your review. Updated the PR per the comments.

[mantis-toboggan-md]

I don't think you have to add a prop to the i18n mixin to render the name in a way that matches the list view, as required in the ticket harvester/harvester#2563. This should render the same way:

<span v-else>
   {{ t(`resourceDetail.header.${realMode}`, {subtype: resourceSubtype, name:displayName}, {raw:true}) }}
</span>

[WuJun2016]

@mantis-toboggan-md This is very strange.

1. The raw parameter indicates that we want it to convert the html correctly. (But here we don't want it to convert, the html stays as it is)，
2. {raw: true} should be changed to true，

   dashboard/shell/plugins/i18n.js

   Line 27 in a71dee8

   Vue.prototype.t = function(key, args, raw) {

[WuJun2016]

The question here is, how should I interpret the raw parameter inside Vue.prototype.t.
If raw here is the same as raw in Vue.component, then I think it makes sense to add escapehtml prop,

[mantis-toboggan-md]

{raw: true} should be changed to true，

You're absolutely right, I apologize for being confusing. The way I wrote it is wrong but "worked" because of how this if statement is written:

dashboard/shell/plugins/i18n.js

Lines 20 to 24 in a71dee8

	if ( raw ) {
	return out;
	} else {
	return escapeHtml(out);
	}

My solution works because Vue interprets expressions in {{}} as plain text. So these two examples do not render the same way:

<t v-else :k="'resourceDetail.header.' + realMode" :subtype="resourceSubtype" :name="displayName" raw />
<span v-else>
  {{ t(`resourceDetail.header.${realMode}`, {subtype:resourceSubtype, name: displayName}, true) }}
</span>

<t raw> will not call escapeHtml on the translation string, and will set the element's innerHTML to include raw (aka unescaped) html. That would render the example text <strong><em>something_interesting</em></strong> as something_interesting

dashboard/shell/plugins/i18n.js

Lines 89 to 94 in a71dee8

	if ( this.raw ) {
	return h(
	this.tag,
	{ domProps: { innerHTML: msg } }
	);
	} else {

When we use t(<translation key>, <translation args>, true) inside {{}}, t returns a string with HTML unescaped, but the html is rendered as plain text by vue anyway. I think this is also why, in the original issue, we saw html tags as plain text in the list view:

dashboard/shell/components/formatter/LinkDetail.vue

Lines 45 to 47 in a71dee8

	<n-link v-if="to" :to="to">
	{{ value }}
	</n-link>

value in the issue example is "<strong><em>something_interesting</em></strong>" but then, because it is in {{}}, it is rendered as plain text.

I think needing to render a translation containing user input is rare, so I didn't want to add a prop to i18n mixin to handle this one situation. Having said that I understand that my solution relies on a detail of Vue implementation instead of something we have explicitly written in the codebase, so if the code is not clear enough and you want to keep the prop I'm okay with that.

[WuJun2016]

Yes, I think it might be good to keep this prop.