Looks liek we need a rebase here.

@Hexix23 please rebase.

Rebased onto latest main.

This PR was merged into the repository. The changes were merged into the following branches:

• main: 6c41f5c
• 22.0.x: 1ee224c

Hello,

It looks like this change introduces a breaking behavior, but it was released as part of a patch version.

Could you please advise on the recommended migration path for cases where attributes contain on as part of their name but are not event bindings? One example is the scenario described here: telerik/kendo-angular#4945.

From a consumer perspective, it is unclear how such attributes should now be translated without being incorrectly treated as events. Could you please confirm this was the intended approach, or consider applying a fix if this behavior was not intentional?

Thank you.

@Raisolution, with i18n any attribute even unbound ones can theoretically be exploited for XSS during i18n processing, that isn't the root cause here. In this specific scenario, the issue arises because the attribute is literally named on, which causes it to be incorrectly flagged as a potential event handler.

#69306 should fix this particular case.

@alan-agius4 thank you for the clarification.

Yes, the issue is caused by the attribute name being interpreted as a potential event handler. This is the reason for raising the question - there are many valid translation attributes/messages where the name may start with on, without representing an event handler.

Could you please advise what the recommended approach is for such valid i18n cases, should consumers rename all such attributes/messages?

Edit: Thank you for the fix. It handles the concrete case with the word on, but the general problem will still be present. Would it be possible to list the concrete event-handler attributes that are considered problematic, instead of treating all attributes starting with on as unsafe?

Thank you.

@Raisolution, we could add a comprehensive list, but it would drastically increase the bundle size by almost 1kb (minified) since there are 73 handlers starting with the on prefix. Note: the current check is also current used for bindings.

Can you provide examples of attributes starting with on that aren't handlers?

Generally, I'd recommend keeping attributes starting with on prefix reserved strictly for event handlers.

@alan-agius4 thank you for the prompt reaction and for providing the fix.

In the specific case, I do not currently have other concrete examples, the concern was more general, as there are valid words/messages starting with on that could theoretically hit the same problem.

That said, the proposed fix addresses the reported scenario, thank you again for the quick turnaround. 🍻