binding icon indicating copy to clipboard operation
binding copied to clipboard

click.delegate bindings intermittently execute more than once in an Aurelia application

Open massimocode opened this issue 1 year ago • 5 comments

I'm submitting a bug report

  • Library Version: 2.5.4

Please tell us about your environment:

  • Operating System: Windows 11 (same issue on Windows 10)

  • Node Version: v20.17.0

  • NPM Version: 10.8.2

  • JSPM OR Webpack AND Version webpack 5.91.0

  • Browser: Chrome v128 (although this issue has existed on versions much earlier too, definitely as far back as v108 and extremely likely earlier than that).

  • Language: Typescript 5.4.5

Current behavior: We have a front-end application built using Aurelia. We have some automated UI tests for it. Sometimes our UI tests will fail. We added much more in-depth logging and found that it was because buttons that had the click.delegate binding on it were executing the handler more than once when they were clicked. So our test was clicking the element once, but the handler was running more than once.

When we changed those handlers to use click.trigger, we could no longer reproduce it.

We have also seen this behaviour in our production application, where users who we believe to be normal users (as we looked at their analytics sessions and didn't see any bot like behaviour) were submitting forms multiple times in extremely quick succession, impossibly quick for a user.

Expected/desired behavior: When click.delegate is used, the handler should be called only once. (Most of the time this is the case, but as I mentioned there see to be cases where it is not).

  • What is the expected behavior? To only call the click handler once.

  • What is the motivation / use case for changing the behavior? I suspect that this is a bug in Aurelia, as changing the binding from delegate to click seems to solve the problem.

I could not replicate this using a simple gist (1 App viewmodel, no routing) but I have a repository with tests that fail quite reliably when run multiple times.

I'm looking forward to hearing your thoughts and trying anything that you'd like me to try.

The application is 4 years old and this issue has existed for pretty much as far back as I can remember. I also remember seeing this issue whilst working on another Aurelia application as far back as 2016.

massimocode avatar Sep 19 '24 12:09 massimocode

Thanks @massimocode , ill see if I can guess-locate the code without a repro.

bigopon avatar Sep 30 '24 09:09 bigopon

Those I should also say that click.delegate is no longer recomended, as the pros are longer worth the cons.

bigopon avatar Sep 30 '24 09:09 bigopon

Thanks for confirming @bigopon. In that case we will switch over to click.trigger instead. We don't use it heavily with hundreds/thousands of elements on a page anyway and I think that was the main driving factor for click.delegate.

It might be worth a quick update to the docs that either delegate shouldn't be used anymore or perhaps should only be used with many repeated elements or something.

I'm happy to try anything you want (i.e. add logging statements or amendments) to help look into this issue if you wish to pursue it.

massimocode avatar Sep 30 '24 10:09 massimocode

Yes, we should do that. Ccing you @Vheissu for the note in our new v1 doc.

bigopon avatar Oct 02 '24 14:10 bigopon

I'm happy to try anything you want (i.e. add logging statements or amendments) to help look into this issue if you wish to pursue it.

Thanks, if I do I will try to ask for help when needed 🙏 .

bigopon avatar Oct 02 '24 14:10 bigopon

@bigopon I know I'm late to the discussion, but I've just hit this bug on our v1 codebase. It seems like it's really easy to trigger the behavior if you bootstrap 2 separate applications on the same page.

If both applications have a click.delegate binding, then the framework will add a click handler to the document twice, and each of those two click handlers will trigger events from both applications.

haltesh avatar Jul 24 '25 05:07 haltesh

Thanks @haltesh i remember this behavior. Its one of the thing that got fixed in v2. Where an event handler will be attached to the root of the application instead of document. It can be fixed without introducing a breaking change, likely so. But im not sure if we should introduce that fix instead of encouraging apps to move to trigger.

bigopon avatar Jul 24 '25 05:07 bigopon