Custom Impersonation Menu disappears and crashes (Grey Screen) on specific Portal Pages
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
13 hours ago
Hi everyone,
I’m facing a persistent issue with a custom impersonation feature in our Service Portal.
The feature works perfectly on the index page, but fails consistently on a custom cloned version of the Service Catalog category page and another pages.
The Setup:
Header: A custom widget where the "Impersonate User" option is coded inside the User Avatar dropdown menu.
Mechanism: A Client Controller function calls spModal.open to load a widget named impersonate_user_widget.
Page Specifics: The issue primarily occurs on a specific page (customized version of sc_category).
The Symptoms:
Disappearing Act: On a page reload or when navigating to the category page, the "Impersonate" link frequently disappears from the avatar dropdown, even though the user has the correct roles.
The "Grey Screen": When the link is visible and clicked, the page often becomes unresponsive with a permanent modal backdrop (grey screen), and the modal itself never appears.
Console Errors / Logs:
Node cannot be found in the current page.
Unload event listeners are deprecated and will be removed. (Warning)
amb.MessageClient [INFO] >>> connection exists, request satisfied (Standard AMB logs, but UI remains locked).
Codes:
Header HTML (Inside User Dropdown):
<ul class="dropdown-menu" role="menu"> <li role="presentation"> <a href="javascript:void(0)" ng-click="c.openImpersonateModal()"> Impersonate User </a> </li> </ul>
Client Controller Logic:
c.openImpersonateModal = function() { spModal.open({ title: 'Impersonate User', widget: 'custom_impersonate_widget', size: 'md' }).then(function() { // success logic }, function() { // Cleanup for stuck grey screen/backdrop $('.modal-backdrop').remove(); $('body').removeClass('modal-open'); }); };
Link:
function(scope) {
var $uibModal = $injector.get('$uibModal');
// Observa o menu do utilizador no DOM
var lookForMenu = setInterval(function() {
// Suporte a PT / EN
var $userMenu = $('ul.dropdown-menu[aria-label*="User"], ul.dropdown-menu[aria-label*="Usuá"], ul.dropdown-menu[aria-label*="Opç"]');
// Menu encontrado e link ainda não inserido
if ($userMenu.length > 0 && !$('#impersonation').length) {
if (scope.data.show_menu_entry) {
var linkHtml =
'<li role="presentation" style="cursor: pointer;">' +
'<a role="menuitem" tabindex="-1" id="impersonation">Impersonate User - Diego</a>' +
'</li>';
$userMenu.find('li:first').after(linkHtml);
// Evento clique
$(document)
.off('click', '#impersonation')
.on('click', '#impersonation', function(e) {
e.preventDefault();
$uibModal.open({
templateUrl: 'impersonate-widget',
scope: scope
});
});
}
// Para após sucesso
clearInterval(lookForMenu);
}
}, 250); // Intervalo de verificação
// Timeout de segurança
setTimeout(function() {
clearInterval(lookForMenu);
}, 10000);
}
What I’ve attempted:
Used $timeout to ensure the modal launch is outside the initial Angular digest cycle.
Verified that permissions are correctly passed via the Server Script.
Manually cleaned up the modal-backdrop via jQuery in the catch block of the modal promise.
Checked for any "Invalid JSON" errors in the Widget Instance options of the problematic page.
Temporarily removed search widgets from the page to rule out focus-trapping issues.
Has anyone seen an instance where a specific page layout or container configuration interferes with the Header Widget's ability to render modals? It seems like a race condition where the page's heavy DOM is causing the Header's scripts to lose their reference point.
Any insights on how to further debug a "Grey Screen" when there is no clear JavaScript stack trace would be greatly appreciated!
