GNOME Bugzilla – Bug 745407
Opening invalid yelp link results in uncloseable modal help dialog
Last modified: 2015-03-02 23:06:30 UTC
I'm on gnome-terminal version 3.6.2 Caution: following these instructions may result in your session being unusable. You may have to exit to a local tty or ssh in externally to kill things to recover your session. Steps to reproduce: 1) In gnome terminal, "echo INFO:Foobar" 2) right click "INFO:Foobar" and click "Open Link" 3) Close the dialog that opens What should happen: - Other applications should remain usable while yelp is open - The dialog should close, and you can resume using the terminal What actually happens: - Yelp re-opens almost immediately, and continues reopening every time you attempt to close it. - Yelp opens modally / steals focus from all desktop applications
Hi null, Thanks for taking the time to report this bug. However, you are using version 3.6.x which is too old and not supported anymore by GNOME developers. GNOME developers are no longer working on that older version, so unfortunately there will not be any bug fixes by GNOME developers for the version that you use. By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME. Please feel free to reopen this bug if the problem still occurs with a recent version of GNOME, or feel free to file a bug report in the bug tracking system of your Linux distribution if your distribution still supports your version 3.6.x
Still valid in 3.14.x
Certainly not a gnome-terminal bug.
wow, thats pretty annoying. we should really fix this for 3.16
some observations: - this only happens with uppercase INFO: - can be reproduced by running yelp directly: yelp INFO:fubar
So, whats apparently happening here is that yelp treats anything that doesn't have a recognized scheme but contains a : as an 'external uri', and calls g_app_info_launch_default_for_uri on it. Ironically, for INFO:, gio determines that the default handler is...yelp, so yelp activates itself recursively.
Created attachment 298354 [details] [review] Avoid activating ourselves recursively We consider INFO:foobar an 'external uri', and call g_app_info_launch_default_for_uri on it. Which is bad, since GIO promptly determines the default handler for INFO: uris to be...yelp. Avoid this by manually looking up the default handler, and ignoring it if it appears to be yelp.
Review of attachment 298354 [details] [review]: URI schemes are case-insensitive, according to RFC3986, so this seems fine to me. Yelp might want to handle "unknown" schemes more intelligently, but this seems OK as a workaround.
Attachment 298354 [details] pushed as adb5cce - Avoid activating ourselves recursively
*** Bug 464111 has been marked as a duplicate of this bug. ***
*** Bug 742409 has been marked as a duplicate of this bug. ***