Problem/Motivation

There seems to be an issue with the debounce logic. When I quickly type something, I get no results. Additionally, multiple console errors appear:

Error fetching data: DOMException: The operation was aborted.
handleAutocomplete https://whathappens.test/modules/contrib/tagify/js/tagify.js?v=1.0.11:273
onInput https://whathappens.test/modules/contrib/tagify/js/tagify.js?v=1.0.11:326
later https://whathappens.test/core/misc/debounce.js?v=10.2.4:37
setTimeout handler*Drupal.debounce/< https://whathappens.test/core/misc/debounce.js?v=10.2.4:42
trigger https://cdnjs.cloudflare.com/ajax/libs/tagify/4.26.0/tagify.min.js:1

Steps to reproduce

I made a screen recording to illustrate the issue. The first time around it doesn't happen, but the second time it does. I'm able to work around the issue by removing one character, waiting for the spinner to disappear, and re-entering the last character again. In that case results appear.

CommentFileSizeAuthor
#6 3452045-firefox-gin-theme.gif269.11 KBgxleano
#6 3452045-chrome-claro-theme.gif217.54 KBgxleano
CleanShot 2024-06-03 at 09.54.50.mp41.99 MBdieterholvoet

Issue fork tagify-3452136

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

DieterHolvoet created an issue. See original summary.

gxleano made their first commit to this issue’s fork.

gxleano’s picture

gxleano commented

Hi Dieter,

I've been testing the issue, and everything works fine on my end. The browser console shows the AbortError when a request is aborted (e.g., when the input value doesn't match any suggestion and it has been typed quickly), but this error does not affect the behavior of the Tagify element.

I will test this more carefully, but it should not be a big issue.

dieterholvoet’s picture

dieterholvoet commented
Status: Active » Postponed (maintainer needs more info)

This one might also have been fixed in #3411891: Add support for custom form-element supporting entity_reference. I applied that one as patch to my project and I'm running it on production now, will report back if this happens again.

dieterholvoet’s picture

dieterholvoet commented
Status: Postponed (maintainer needs more info) » Active

Just tested and it's definitely still happening. Not all the time though, the problem is that it sometimes doesn't show results even though it should. Not sure if it matters, but I should probably note that I'm using Firefox.

gxleano’s picture

gxleano commented
StatusFileSize
new 3452045-chrome-claro-theme.gif217.54 KB
new 3452045-firefox-gin-theme.gif269.11 KB

On Firefox with the Gin theme, the AbortError occurs every time I type at a normal speed—not too fast, not too slow.

On Chrome is more difficult to reproduce it, but it is also reproducible using Claro as default theme.

In both cases, the suggestion dropdown correctly shows all relevant content without any issues.

See evidences:

Claro - Chrome
Abort error in Tagify widget

Gin - Firefox
Abort error in Tagify widget using Gin theme

gxleano’s picture

gxleano commented

I've been checking between versions and 1.2.11 doesn't have the "bug", so the "bug" was definitely introduced here: https://www.drupal.org/project/tagify/releases/1.2.12, but I need some time to debug it in depth.

gxleano’s picture

gxleano commented

Seems like the problem is related with the wait time in the Drupal.debounce.

@param {number} wait
  The time period within which the callback function should only be
  invoked once. For example if the wait period is 250ms, then the callback
  will only be called at most 4 times per second.

We removed the wait parameter from the input in 1.2.12

gxleano opened merge request !95

gxleano’s picture

gxleano commented
Status: Active » Needs review
gxleano’s picture

gxleano commented
Status: Needs review » Needs work
gxleano’s picture

gxleano commented
Status: Needs work » Needs review
dieterholvoet’s picture

dieterholvoet commented

I tested all commits you did separately. A 250 wait time works, but honestly 50 feels a lot snappier/more fluent to me. Why did you change to 250?

gxleano’s picture

gxleano commented

Hi Dieter,

Thanks to take a look on this.

If we set the wait time to 50ms in the debounce function, it is making the tests fail.

See:

@param {number} wait
  The time period within which the callback function should only be
  invoked once. For example if the wait period is 250ms, then the callback
  will only be called at most 4 times per second.

I need to find some time to figure out how we can fix this in the best way.

dieterholvoet’s picture

dieterholvoet commented

Okay, I noticed 50 works great on my local environment, but it doesn't work on production. 250 works on both. This is probably a performance thing, depending on how long page loads take. In that case 250 is probably a safer bet - or maybe something in between. I'll try out some different values on production.

dieterholvoet’s picture

dieterholvoet commented

150 seems to work on both as well. I'll go for that value on my website right now, but maybe it would be best to make this configurable (or at least alterable through some hook) in order to improve responsiveness on faster sites.

dieterholvoet’s picture

dieterholvoet commented

Never mind, 150 still fails sometimes. 250 seems to be a good default.

dieterholvoet’s picture

dieterholvoet commented
Status: Needs review » Needs work

It still fails randomly, depending on how fast you type, and the Error fetching data: DOMException: The operation was aborted errors still appear in the console. I feel like there's still something else going wrong, other than the configured timeout.

gxleano’s picture

gxleano commented
Status: Needs work » Needs review
gxleano’s picture

gxleano commented
dieterholvoet’s picture

dieterholvoet commented

I noticed that when you're typing fast in the autocomplete field, for every keystroke, a new request is sent to the server. Previous requests are aborted by the client on the next keystroke, but the request is still sent to the server, causing unnecessary load. Could you maybe implement some sort of debounce function to make sure that doesn't happen? Apart from that, everything seems to work alright. I'm updating the patches on a couple production projects I'm using regularly, so I'll report back if I encounter any strange behaviour in the next weeks.

gxleano’s picture

gxleano commented

Thanks Dieter for the quick feedback!

gxleano’s picture

gxleano commented

The main issue was the 'no matching item' message which was appearing immediately after typing, even when a match existed. This was caused by the lack of debounce on the dropdownItemNoMatch function, which resulted in an early feedback. To fix this, I've wrapped dropdownItemNoMatch in a debounce, ensuring smoother performance and preventing the message from displaying unnecessarily.

dieterholvoet’s picture

dieterholvoet commented
Status: Needs review » Reviewed & tested by the community

This seems to work very well! For a long time, the Tagify widget was a bit buggy. The changes here seemed to have fixed that. I'll let you know if I encounter anymore weirdness, but during my testing in the past days everything seemed okay.

gxleano’s picture

gxleano commented

Thanks for the review Dieter!

It will be included in 1.2.30 release.

gxleano’s picture

gxleano commented
Status: Reviewed & tested by the community » Fixed

  • gxleano committed e10fe7a7 on 1.2.x 
    Issue #3452136 by gxleano: Add wait parameter to Drupal.debounce method
gxleano’s picture

gxleano commented
Status: Fixed » Closed (fixed)