Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom actions are triggered on hover (not click!) in 3.2 #3701

Closed
MichaelHoste opened this issue Sep 27, 2024 · 4 comments
Closed

Custom actions are triggered on hover (not click!) in 3.2 #3701

MichaelHoste opened this issue Sep 27, 2024 · 4 comments

Comments

@MichaelHoste
Copy link

Hi there, we found what we think is a very serious issue in the 3.2 release.

Describe the bug

It seems that with this new release, when a link is hovered, the linked page is preloaded in the background. Maybe it's a new default behavior of turbo-rails?

The issue is that it also preloads custom actions ⚠️

As you may have guessed, custom actions are usually destructive actions (remove user, charge payment, cancel payment, etc.) and these destructive actions are now triggered silently just by hovering the button.

Reproduction steps

Here is what happened to us (luckily in staging!), users were silently removed just by hovering a button:

Screen.Recording.2024-09-27.at.11.51.38.mov

Expected behavior

Is it really useful to preload every hovered link?
I guess we should at least disable this behavior from custom actions.

Additional context

  • rails version: 7.0.8.4
  • rails_admin version: 3.2
@mshibuya
Copy link
Member

mshibuya commented Oct 6, 2024

This behavior change is due to change in Turbo 8 (turbo-rails >= 2.0), which introduced the prefetch feature.
https://turbo.hotwired.dev/handbook/drive#prefetching-links-on-hover
Considering the existing custom actions use cases, I disabled the prefetch behavior globally for now. The fix is already in the master branch, so please try. If it works for you I can cut a new release.
f54a102

At the same time I don't recommend GET method actions to have a mutating behavior, as it's against the HTTP standard. I'm planning to enhance the custom action to support POST only actions, so people don't need to use GET for that purpose.

@didier-84
Copy link

@mshibuya Thank you very much for having taken the time to look into this.

I'm working with @MichaelHoste, who opened this issue, and we have just tried your fix (f54a102).

I confirm that it works as expected. Thank you!
We're looking forward to the next release 🚀

We agree with you: the GET method should not be used for actions that have a mutating behavior. Enhancing custom actions to support the POST method, as you just suggested, would be the ideal solution for us (and many other developers).

@mshibuya
Copy link
Member

Thank you for reporting back! Just released 3.2.1 🚢

@MichaelHoste
Copy link
Author

3.2.1 release fixes our issue, but we also added this block in our custom actions just to be sure it won't happen again.

register_instance_option :turbo? do
  false
end

Thank you for this quick fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants