-
Notifications
You must be signed in to change notification settings - Fork 47.2k
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
Bug: React DevTools failing silently on Debian #20120
Comments
Would you be interested in adding a section to the standalone DevTools PR for other Linux users? Issues like this have come up before (see #19976). |
Can I have a go at this @bvaughn |
Yes. |
Experiencing this as well. Let me know if there are other workarounds. Modifying the kernel does not seem like a great option for most users. |
PR #20496 updates Electron from v9 to v11 (the latest stable release). If Electron itself does not support an OS– that's not something the React team can tackle (no bandwidth). I'd welcome an update to the DevTools README that at least calls this out, but that would need to be community driven. (I don't even have a way to test or debug this myself, so there's not much I can do.) Tempted to close this issue since it's not very actionable for us. |
@bvaughn is it accurate to say that by switching from v9 to v11, in order to add support for one OS, it broke support for another OS? |
No? What Os was broken by the switch from v9 to v11? We haven't even released that change yet. This issue was broken prior to that upgrade. My point in mentioning it was that– beyond upgrading to the latest Electron, there isn't much we can do on our end (short of a major rewrite to move away from Electron entirely- which we don't have the bandwidth for). |
I agree with you @bvaughn, this has nothing to do with react devtools itself, and the problem is present since react devtools switch to Electron version > 5, so quite a long time I'd say. I confirm the switch from v9 to v11 isn't related to this issue, since it's there since Electron v5. To recap what could be done to solve this issue on the user side:
|
I'd welcome a PR that updates the README for standalone to add a section for Debian. |
a related note about the "failing silently" part in this line we should check |
happy to open a PR if someone confirms what the correct behavior should be |
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment! |
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you! |
React version: react-devtools v4.9.0
Steps To Reproduce
The current behavior
The command fails silently and nothing happens.
The expected behavior
React DevTools should start and connect to app.
I am not sure this is the right place to post this, but since I know how to fix this issue and I think other people might face it, I'm opening this thread to also post the solution.
I run into this issue on Linux (debian bullseye with kernel 5.7.0). The main problem is connected to Electron (afaik since version 5) not being able to launch without binary being owned by root and chmod 4755. The issue is with the new sandbox and the priviledges it requires to launch.
There is also another workaround I found some months ago on the dedicated thread from Electron's GH (since this is a common issue for Linux users of all Electron applications) that works for every packaged Electron app and binary.
Instead of modifying the electron binary permissions, you can instead tweak an option of your running kernel by doing:
Then your Electron apps will launch, and thus so will React DevTools.
Feel free to close this if it isn't relevant here (since not really an issue with devtools itself, rather with Electron x Debian), but I haven't found anything regarding this matter and I think someone might encounter this issue in the future (hoping I'm not totaly mistaken about this to begin with 😄)
The text was updated successfully, but these errors were encountered: