Known issues in Experience Manager
The following list describes issues that are known to exist in Experience Manager.
- Safari may require repeated sign-in
-
When using the Safari browser with a certain experimental feature, the user is required to repeat the sign in process after doing a browser refresh. This issue occurs only under the following conditions:
- Safari is using the experimental feature
NSUrlSession Websocket. In some versions of Safari, this feature is selected by default and can include a bug that causes the sign-in issue. - User authentication is not being managed through Access Management.
To work around this issue (without migrating security to Access Management), the user should turn off the option in the browser's settings. This option is generally found under the .
- Safari is using the experimental feature
- Browser may block user from signing in when authenticating through Access Management
-
In some cases, the user may be prevented from signing in due to the browser's pop-up blocker. This issue occurs in under the following conditions:
- The environment is using Access Management for authentication.
- The user is using one of the following browsers: Chrome, Safari or Microsoft Edge.
- Pop-up blocking is enabled, which is generally the default.
To work around this issue, the user should select the browser's option to allow the authentication popup.
- Chrome does not allow user to open Experience Manager
-
When using SAML authentication for Content Manager security in combination with Chrome 80 and later, Chrome prevents users from editing content in Experience Manager and may show a Javascript error in Chrome's debug console. This issue is due to an update in Chrome 80 and introduction of a SameSite cookie classification, which blocks any cookies that are not labeled in a certain way. After this update, Chrome no longer classifies Experience Manager as safe. As a workaround, we recommend that you configure Content Manager security so that SAML will not authenticate the Experience Manager URLs that allow editing content.
- Chrome and Safari do not show sizing handles for tables and images in a Format Area
-
In Chrome and Safari for the Mac, selecting an image or table in a Format Area does not make sizing handles appear on the item's edges. As a result, users cannot resize images or tables in this way.
To work around this problem, users must either use a different supported browser, or set the width and height as numbers.
- In a legacy (in-process) .NET Web site on which Preview is enabled, users (even non-authenticated ones) can create folders and pages by browsing to a nonexistent URL
-
In this scenario, a user enters a nonexistent URL in their browser's address bar, which starts with the base URL of a Preview-enabled, in-process, .NET Web site. For example, given http://example:82/ as a base URL, the user enters http://example:82/foo/bar.aspx, even though no folder
foonor a pagebar.aspxactually exist on the site.The act of browsing to such a URL, in itself, causes the folder and ASPX page (with empty content) to be created.
To work around this problem, you can migrate your setup from in-process to the new RESTful offering.
- Editing a very large PNG image can cause it to become impossible to save
-
If you use Image Editor to edit an image in PNG format, its file size can increase by a factor 3. The edited file can then become impossible to save back to Content Manager, because its new size exceeds the maximum allowed upload size (as configured in %TRIDION_HOME%\Web\Web.config. If this happens, you see an error message: "Error saving edited image."
To work around this issue, either ensure that the configured maximum upload size is at least 3 times the size of your largest PNG file, or use images in a different file format (like JPEG) instead.