-
Context-specific toolbar actions are not available in vSphere Client 6.5 and 6.7
The vmware.prioritization.action extension point is not supported for developing HTML plug-ins for the vSphere Client 6.5 and 6.7.
However, you can implement your own context-specific toolbar actions as shown in the HTML SDK sample.
-
Localized labels of a plug-in were not shown.
The localized labels of a plug-in were sometimes not shown after you deploy a new plug-in. Property keys would be displayed instead of user meaningful text.
This problem has been resolved.
-
Chassis object property updates do not appear.
The vSphere Client does not show updates to a Chassis object until you refresh the view. When you select Edit Chassis and modify properties, then click Update Chassis, the object updates in memory but the changes do not show immediately.
Workaround: Click the Global Refresh button, and the view updates the properties on the screen.
-
Global refresh error with plug-in portlet
The Global Refresh button causes internal error #1009
if the user clicks the button upon first entry to a view containing a plug-in portlet.
This problem is caused by a limitation in the SDK.
Workaround: Navigate to another view with a plug-in portlet,
then back to the original view, before clicking the Global Refresh button.
Shell scripts had bad line end characters.
All .sh script files have the correct end of line character and no longer report the error "^M: bad interpreter: No such file or directory".
-
WEB_PLATFORM.getString() now works when many parameters are passed.
-
When you close a dialog box with the ESC key
or by clicking the X box,
vSphere Client no longer encounters errors.
-
Plug-in dialog boxes no longer are cut off when the screen is too small.
The known issues are grouped as follows.
-
The log files of the Virgo server are missing on Japanese OS installations
Workaround: To resolve this issue, you can try the following:
-
Open the vSphereWebClient\configuration\serviceability.xml file with a Hex editor.
-
Remove the first three invisible bytes (EF BB BF) and save the file.
-
Restart the service of the vSphere Client.
-
The WEB_PLATFORM.setDialogSize() API is not supported in the vSphere Client
You can use the WEB_PLATFORM.setDialogSize() function to change the size of the dialog box at runtime when developing HTML-based plug-ins for the vSphere Web Client. This function is not supported for developing HTML plug-ins for the vSphere Client 6.5 and 6.7.
Workaround: For developing HTML plug-ins for the vSphere Client, you can set the size of the dialog box upon opening the dialog.
-
String resources are not reloaded when you use the pickup directory to deploy your HTML plug-ins
The WAR bundle of an HTML plug-in contains localized string resources that are visible in the UI. In a development environment, if you use the pickup directory of your local vSphere Client to deploy and test your HTML plug-ins, you must first deploy the WAR bundles of your plug-in package. When you update the WAR bundles, the Virgo server does not reload automatically the localized string resources.
Workaround: You must restart the vSphere Client Virgo server after updating the WAR bundles in the plugin-packages folder.
-
The ${namespace}.manage.tagsViews extension point is not supported in vSphere 6.5 and later releases.
In the vSphere Client, you can no longer add a view under the Tags second-level tab of the Configure tab by using the ${namespace}.manage.tagsViews extension point. You can find the Tags second-level tab under the Tags & Custom Attributes application in the vSphere Navigator.
Workaround: None. If you have existing HTML-based plug-ins that use the ${namespace}.manage.tagsViews extension point to add views under the Tags second-level tab, you must change their implementation to use another extension point.
- Two portlets in the same plug-in cannot share the same URL.
When a vSphere Client plug-in contains two portlets, they must specify different values for their attributes. Otherwise, a global refresh operation updates only one of the portlets.
Workaround:Assign different URLs to the two portlets. For example:
<extension id="portlet1">
...
<url>/vsphere-client/chassisa/resources/host-portlet1.html</url>
...
</extension>
<extension id="portlet2">
...
<url>/vsphere-client/chassisa/resources/host-portlet2.html</url>
...
</extension>
-
Google Chrome problem with WEB_PLATFORM.
Several method calls in the WEB_PLATFORM container app in the Flex-based client
work the first time an HTML plug-in opens, but fail on subsequent calls.
Calls that fail include WEB_PLATFORM.getObjectId(), WEB_PLATFORM.getActionUid(),
and others.
This problem happens with HTML plug-ins running on the Flex-based vSphere Client
on Google Chrome (version 55.0.2883.87 and later).
Workaround: To resolve this issue,
update the file web-platform.js with the following code
and rebuild your plug-in:
var WEB_PLATFORM = self.parent.WEB_PLATFORM;
var isChromeBrowser = (window.navigator.userAgent.indexOf("Chrome/") >= 0);
var isFlexClient = !!self.parent.document.getElementById("container_app");
if (!WEB_PLATFORM || (isChromeBrowser && isFlexClient)) {
WEB_PLATFORM = self.parent.document.getElementById("container_app");
if (isChromeBrowser) {
// Object.create is required to support Chrome version >= 55 on Flex client
WEB_PLATFORM = Object.create(WEB_PLATFORM);
}
self.parent.WEB_PLATFORM = WEB_PLATFORM;
- Plugin localization does not fallback to en.
If the plug-in does not support the current vSphere Client locale, the plug-in will not fall back to English, and the UI will display keys instead of localized values.
Workaround: Include a default properties file (com_myplugin.properties) with the plug-in. The properties file must have no country and language suffix. This properties file takes effect when the vSphere Client has an unsupported locale.
- Virgo server using incorrect context path when started from Eclipse.
You can start the Virgo server in your development environment in one of two ways: either by using the startup script or by using Eclipse.If you start the Virgo server from Eclipse, it adopts the context path of the vSphere Web Client rather than the context path of the vSphere Client. The Virgo log shows this entry:
[2018-03-27T17:52:54.982-07:00] [INFO ] start-signalling-1 org.eclipse.virgo.medic.eventlog.default WE0000I Starting web bundle 'com.vmware.samples.globalviewhtml' version '1.0.0' with context path '/vsphere-client/globalview'.
The correct context path for the vSphere Client is /ui/globalview rather than /vsphere-client/globalview.
Workaround:There are two workarounds available:
- Start the Virgo server from the command line with the
startup.bat or startup.sh script.
- Add the following two arguments to the list of VM arguments in the launch configurations of the Virgo server:
-Dweb.context.path.match=vsphere-client
-Dweb.context.path.replace=ui
- Memory leak with Microsoft Internet Explorer 11.
vSphere Client's memory consumption increases steadily when using Microsoft Internet Explorer 11 with iframes in vSphere Client plug-ins. (This issue is reported at https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8449104/)
Use other browsers supported with the vSphere Client, such as Chrome or Firefox.