WHMCS 8.13–9.0.9: Ticket reply editor randomly loses focus and sometimes submits replies

[Internet.AM]

We've been dealing with this extremely frustrating issue since WHMCS 8.13, and it's still happening in 9.0.9.

While typing a normal support ticket reply, the Markdown editor suddenly loses focus and the cursor jumps into the ticket status dropdown directly below the editor.

For example, I start typing cPanel. The letter c stays in the reply editor, while Panel ends up in the status dropdown. No mouse clicks, no switching windows, nothing. It just happens randomly in the middle of typing.

Even worse, sometimes the reply gets submitted unexpectedly, without me clicking the Reply button.

I'm using Chrome on Windows. I've disabled every browser extension, but the problem persists.

This has been happening across multiple WHMCS versions, so it's clearly not something introduced yesterday.

Has anyone else experienced this exact behavior? More importantly, has anyone found an actual fix?

It's incredibly frustrating to have to constantly watch where your text is going while replying to support tickets, especially when there's also a risk of accidentally sending an unfinished reply.

[websavers]

I have not experienced, this. I wonder if it might be caused by javascript within a WHMCS module or your admin area theme (if not default / blend).

[auxilex]

I have experienced the same issue on the default Blend theme. Start typing, the cursor jumps down to the status box and typing continues there. Not aware of any fix at the moment unfortunately. 

Edited Monday at 11:49 PM by auxilex

[D9Hosting]

I came across this and found the issue only occurred if you have the Chrome password manager set to store your admin username and password. For some reason Chrome is seeing the ticket status box as a username field and automatically jumps to this to populate it with your admin username.

I tried a few workarounds but the only thing that fixed it was by telling Chrome to forget the admin username/password for the install.

[ThemeMetro]

As a temporary fix, you may edit the viewticket.tpl file manually and replace the last script block with the updated code in blend template.

From

<script>
$(document).ready(function() {
    if (typeof aiRating !== 'undefined') {
        aiRating.init();
    }	
});
</script>

To

<script>
$(document).ready(function() {
    if (typeof aiRating !== 'undefined') {
        aiRating.init();
    }

	// Prevent Chrome Password Manager autofill in Status Selectize
	function fixStatusAutofill() {

		var statusSelect = document.querySelector(
			'#frmAddTicketReply select[name="status"].selectized'
		);

		if (!statusSelect) {
			return;
		}

		var statusInput = statusSelect.nextElementSibling
			? statusSelect.nextElementSibling.querySelector('input')
			: null;

		if (!statusInput) {
			return;
		}

		statusInput.setAttribute('autocomplete', 'off');
		statusInput.setAttribute('data-lpignore', 'true');
		statusInput.setAttribute('readonly', 'readonly');

		function clearInvalidValue() {

			var currentValue = statusInput.value.trim();

			var validOption = Array.from(statusSelect.options).some(function(option) {
				return option.text.trim().toLowerCase() === currentValue.toLowerCase();
			});

			if (currentValue && !validOption) {
				statusInput.value = '';
				statusInput.dispatchEvent(new Event('input', {
					bubbles: true
				}));
			}
		}

		clearInvalidValue();

		if (!statusInput.dataset.autofillFixed) {

			statusInput.addEventListener('focus', function() {

				clearInvalidValue();
				statusInput.removeAttribute('readonly');

				setTimeout(clearInvalidValue, 100);

			});

			statusInput.dataset.autofillFixed = 'true';
		}
	}

	fixStatusAutofill();

	setTimeout(fixStatusAutofill, 500);
	setTimeout(fixStatusAutofill, 1500);	
	
});
</script>

 

 

Edited 8 hours ago by ThemeMetro

[Waqas Ahmed Waseer]

Nice find on the Chrome password manager, d9hosting. That also explains why some people never see it: it only hits staff who have the admin login saved in Chrome.

One suggestion on ThemeMetro's fix: rather than editing viewticket.tpl in the Blend template, drop the same script into a hook. Template edits get overwritten on the next WHMCS update, while a file in includes/hooks/ survives updates and you don't have to remember to re-apply it. Something like this:

<?php
// includes/hooks/ticket_status_autofill_fix.php
add_hook('AdminAreaFooterOutput', 1, function ($vars) {
    if (basename($_SERVER['SCRIPT_NAME']) !== 'supporttickets.php') {
        return '';
    }
    return <<<'HTML'
<script>
// paste ThemeMetro's script body here, from "// Prevent Chrome Password Manager autofill" down to the setTimeout lines
</script>
HTML;
});

Their script already returns early when the status field isn't on the page, so it's harmless on the ticket list. After adding it, hard refresh a ticket (Ctrl+Shift+R) and check the status box no longer gets the username dropped into it.

Worth adding d9hosting's finding to a WHMCS ticket as well, so the status field markup gets fixed in core, since this affects anyone using Chrome's built-in password manager.

[ThemeMetro]

49 minutes ago, Waqas Ahmed Waseer said:

Nice find on the Chrome password manager, d9hosting. That also explains why some people never see it: it only hits staff who have the admin login saved in Chrome.

One suggestion on ThemeMetro's fix: rather than editing viewticket.tpl in the Blend template, drop the same script into a hook. Template edits get overwritten on the next WHMCS update, while a file in includes/hooks/ survives updates and you don't have to remember to re-apply it. Something like this:

<?php
// includes/hooks/ticket_status_autofill_fix.php
add_hook('AdminAreaFooterOutput', 1, function ($vars) {
    if (basename($_SERVER['SCRIPT_NAME']) !== 'supporttickets.php') {
        return '';
    }
    return <<<'HTML'
<script>
// paste ThemeMetro's script body here, from "// Prevent Chrome Password Manager autofill" down to the setTimeout lines
</script>
HTML;
});

Their script already returns early when the status field isn't on the page, so it's harmless on the ticket list. After adding it, hard refresh a ticket (Ctrl+Shift+R) and check the status box no longer gets the username dropped into it.

Worth adding d9hosting's finding to a WHMCS ticket as well, so the status field markup gets fixed in core, since this affects anyone using Chrome's built-in password manager.

 

Yes, using a hook would be a better solution if WHMCS does not address this issue. However, I believe this should be fixed in an upcoming WHMCS release.