What do developers here use to debug gnome-desktop’s javascript code?
I need to step through the file:
/usr/share/gnome-shell/extensions/ding(at)rastersoft.com/fileItemMenu.js
(substitute @ for (at) which I put there to defeat a spammer’s email address harvester.)
This js file produces a menu that fails to include an expected menu item. I would like very much to step through it just as can be done with a C, or C++, program using gdbgui to find out why.
Stepping through an extension in the way you describe, amounts to stepping through the gnome-shell process. Presumably something like gdb --args gnome-shell --nested --wayland, and breakpoints set with System.breakpoint() would work, but I’m not aware of anyone going to that length for an extension.
If the code can be extracted or is part of a separate process already, it’s probably easier to step through it with the built-in debugger using gjs --debugger FILE.
Does the gjs command wait for gnome to call up the js file? Or does it execute right away the file it is given? To find out why fileItemMenu.js does not do what I expect I would need to step through it when a desktop icon is right clicked.
Sorry, I’m not explaining clearly.
Extensions are in no way separate from the gnome-shell process, so if you want to step through an extension with a debugger, it must step through the entire gnome-shell process. You can add breakpoints that a debugger like gdb will catch by adding System.breakpoint() calls to the JavaScript. When you hit a breakpoint, you can call gjs_dumpstack() in the debugger to print the current JavaScript stack.
If you can separate the problem JavaScript into a standalone file, you can run that with gjs --debugger to step through JavaScript, call-by-call.
Of course, you should not attach gdb or another debugger to your live gnome-shell process, because as soon as you hit a breakpoint you will halt GNOME Shell.
The problem I need to solve is in file:
/usr/share/gnome-shell/extensions/ding(at)rastersoft.com/fileItemMenu.js
Where @ is to be substituted for “(at)”.
And in these lines of code that begin at line 200 in that file:
if (fileItem.isValidDesktopFile && !this._desktopManager.writableByOthers && !fileItem.writableByOthers && (selectedItemsNum == 1 )) {
addSeparator();
addElementToMenu(
fileItem.trustedDesktopFile ? _("Don't Allow Launching") : _("Allow Launching"),
() => {fileItem.onAllowDisallowLaunchingClicked();}
);
}
The menu item “Don’t Allow Launching” / “Allow Launching” does not appear when a launch icon is right clicked in my desktop. I am not able to allow launching, in spite of using the gio command:
gio set "/home/stephen/Desktop/Flameshot.desktop" metadata::trusted true
That this command worked was verified with the command:
gio info -a 'metadata::*' /home/stephen/Desktop/Flameshot.desktop
Group, and Others, can only view this desktop file. The icon is marked executable. All conditions I know to be able to allow launching are met. Yet the desktop icon is still grayed out, and it does not launch. The same is true of any other desktop launcher icon I set up.
So to find out why I now I need to inspect the values of:
fileItem.isValidDesktopFile
this._desktopManager.writableByOthers
fileItem.writableByOthers
selectedItemsNum
I can set a breakpoint at line 200, and see the back trace at that point, but would I be also able to inspect those values?
I have thoughts of backing up the “fileItemMenu.js”, and then editing a temporary version of the file that displays those values in the menu.
It would likely be a lot easier for you to work on an extension installed to /.local/share/gnome-shell/extensions, but that’s another topic.
Why not just edit the file to log the values of those variables? This seems like a much simpler way to get what you want.
Logging seems a better option. I do not know how to do that, but I will find out.
There is guide to Getting Started with extensions, and some tips for Debugging on gjs.guide.
The API docs are at https://gjs-docs.gnome.org and there’s a Matrix channel at https://gnome.element.io/#/room/#extensions:gnome.org
Thank you for your reply. It is helpful.
I decided the easiest way for me to inspect those variable’s values would be for me to modify the menu to display the variable(s) whose value is preventing the display of the “Don’t Allow Launching” / “Allow Launching” item. Using Gnome’s Builder I modified fileItemMenu.js as shown in the below code snippet:
if (fileItem.isValidDesktopFile && !this._desktopManager.writableByOthers && !fileItem.writableByOthers && (selectedItemsNum == 1 )) {
addSeparator();
addElementToMenu(
fileItem.trustedDesktopFile ? _("Don't Allow Launching") : _("Allow Launching"),
() => {fileItem.onAllowDisallowLaunchingClicked();}
);
}
// Start temp debug
else{
addSeparator();
if (!fileItem.isValidDesktopFile) {
addElementToMenu("fileItem.isValidDesktopFile: false ", () => {} );
}
if (this._desktopManager.writableByOthers) {
addElementToMenu("this._desktopManager.writableByOthers: true ", () => {} );
}
if (fileItem.writableByOthers) {
addElementToMenu("fileItem.writableByOthers: true ", () => {} );
}
if (selectedItemsNum != 1) {
addElementToMenu("selectedItemsNum: " + selectedItemsNum.toString(), () => {} );
}
addSeparator();
}
// End temp debug
...
The result is the menu shown in this screenshot:
I am not able to enable launching for any icon on my desktop because the value of : “this._desktopManager.writableByOthers” is true. Right now I do not know how it become true, or how to fix it so it its value is false as it should be. In any documentation I have seen for desktop launchers I have not seen this condition included as a requirement to enable the option to allow launching.
At the time of this posting the link: DevDocs is broken. The error message I get is “Application is not available”. Where is this documentation available?
I was not able to create an account at Element so I could view https://gnome.element.io/#/room/#extensions:gnome.org . The account creation function did not accept my email address’s domain name. It said it was unauthorized.
Sorry, there was a problem with our documentation for a short time. It should be back up now.
This sounds like something you should ask the extension author. Have you reported you problem as an issue with the project?
The code in question seems to be here. This seems to imply the permissions on ~/Desktop allow writing by other users, so launching applications is prohibited for security reasons.
Thank you. 
That solved it. This permissions requirement on the ~/Documents directory needs to be in user documentation.
I see in the code you linked to there is a text message that indicates the problem’s cause on line 1544. I never saw this message printed out anywhere. Where should I have seen this?
Probably it should have been printed to journalctl or GNOME Logs, around the time GNOME Shell started or the extension was loaded.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.