GNOME Bugzilla – Bug 649385
make JS errors more visible to developers
Last modified: 2021-07-05 14:43:07 UTC
see patches. the second one depends on bug 649384
Created attachment 187204 [details] [review] shell-global: make JS errors more visible to developers Override gjs's JS error reporter with our own. When running from the source tree, use shell_global_notify_error() to report JS warnings, to make it more noticeable when new code isn't quite working. Also make shell_global_notify_error() log the error to stderr itself (rather than having the JS handler do it), in case some error prevents the JS handler from being able to run correctly.
Created attachment 187205 [details] [review] shell-global: make uncaught exceptions more visible to developers Add a gjs exception logger, and use that to present uncaught exceptions via shell_global_notify_error, when running from the source tree.
Created attachment 187206 [details] [review] messageTray: improve bad-markup handling _fixMarkup() was supposed to be ensuring that the markup we passed to clutter was correct, but it was validating the syntax incorrectly, and wasn't checking that the markup was valid (or even well-formed). This is bad because if you pass bad pango markup to clutter_text_set_markup(), it will g_warn and drop the string on the floor. Fix by fixing up the regexps, and then calling Pango.parse_markup() on the result, and just xml-escaping everything if parse_markup() fails.
Created attachment 187207 [details] [review] messageTray: add support for <tt> to message tray markup
Created attachment 187208 [details] [review] shell-global: add markup support to shell_global_notify_error() Add markup support to shell_global_notify_error(), and use it to make JS warnings show up in monospace
Created attachment 188063 [details] [review] tests: fix up typelib include paths The js modules have so many imports back and forth that it's pretty much guaranteed that if you import even one of them, you'll end up importing all of them, including ui.status.bluetooth and ui.status.network. So fix up the typelib include paths the same way gnome-shell-jhbuild does, so we can find everything.
Created attachment 188064 [details] [review] tests: add a test for MessageTray._fixMarkup
Comment on attachment 188063 [details] [review] tests: fix up typelib include paths attached to wrong bug
Created attachment 192191 [details] [review] shell-global: make JS warnings and exceptions more visible to developers Override gjs's JS error reporter with our own. When running from the source tree, use shell_global_notify_error() to report JS warnings and uncaught exceptions, to make it more noticeable when new code isn't quite working. Also make shell_global_notify_error() log the error to stderr itself (rather than having the JS handler do it), in case some error prevents the JS handler from being able to run correctly.
Created attachment 192192 [details] [review] messageTray: add support for <tt> to message tray markup
Created attachment 192193 [details] [review] shell-global: add markup support to shell_global_notify_error() Add markup support to shell_global_notify_error(), and use it to make JS warnings show up in monospace
Review of attachment 192191 [details] [review]: ::: src/shell-global.c @@ +504,3 @@ + + if (error) + g_string_append_printf (buf, "%u ", error); Could we save the string from js.msg and use that instead of a useless numerical constant? @@ +550,3 @@ + in_notify_error) + { + g_printerr ("%s", buf->str); I'm not sure I like this - can we print it to stderr in addition to having a source for the first ten messages in-tree? It's helpful for pasting the error to IRC and such. @@ +560,3 @@ + { + g_idle_add (idle_notify_error, + g_strdup ("Further error reports will only be sent to stderr")); Can you include this in the previous message instead of having it as a separate source?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.