GNOME Bugzilla – Bug 331683
Context menu for URLs is racy
Last modified: 2008-10-09 21:07:00 UTC
That bug has been described on https://launchpad.net/distros/ubuntu/+source/gnome-terminal/+bug/28956 "Right-clicking on a URL in a terminal, but accidentally moving the mouse cursor off the URL before the context menu renders (it's easier than it sounds, at least on my hardware) produces a different context menu than if the cursor stays put. Specifically, the "Open Link" and "Copy Link Address" options are missing. It appears that the contents of the menu are determined more by where the mouse cursor is at rendering time than where it was when the right mouse button was clicked. So not only will "Copy Link Address" be missing if the cursor happens to move off the URL you clicked on, it will in fact be present, and copy the wrong URL into the clipboard, if you are unlucky enough to move the cursor over a different URL before the menu appears. For some reason, I trip over this bug almost every day."
I hit this bug quite regulartly too.
Even better. Try this- cat two URLs to a file, or something, to get them right next to each other on screen. Click on one while moving the mouse over the other. What should happen is, the one you clicked on gets opened. But all too often, the one you didn't click on gets opened. The way opening a URL works is, menu_item = append_menuitem (screen->priv->popup_menu, _("_Open Link"), G_CALLBACK (open_url_callback), screen); In other words, it passes the entire screen state off to a callback, not just the matched_string. At first, I thought a potential fix would be to save screen->priv->matched_string and screen->priv->matched_flavor as soon as possible, passing the saved values on instead of whatever the mouse is currently hovering over. But it looks like, because these callbacks are everywhere, that such a solution would be more complicated than I'd like to implement without further discussion.
Is this still reproducible in gnome-terminal from svn trunk?
No response; closing INCOMPLETE.
This bug is still reproducible in 2.22.1, which ships with Ubuntu 8.04 (it's sometimes difficult to build trunk in a distro :3 ). All you need to do to verify this bug is click on a URL and move your mouse off it before the menu is rendered, though I guess if you have a really fast computer it might be harder (can reproduce with a 1.9GHz dual-core Turion64).
reopen as per last comment
I was asking about svn trunk. (Personally I can't repro this on trunk or 2.22.)
Yeah, I know that. However I don't expect every average user to compile from trunk, and the information that the bug IS present at least in 2.22 is something valuable, compared to two years of silence in this ticket.
The code, though different between 2.22 and svn trunk, does in both versions use the coordinates from the button press event to get the URL match string from vte. The possible delay of opening the context menu is only introduced after that, by getting the list of clipboard targets asynchronously. So if this bug exists, it must be that the event coordinates of the button press event are wrong. Can someone who can repro the bug put a few printf's into terminal_screen_button_press in src/terminal-screen.c to print the |matched_string| variable before emitting the context menu signal, and see if it's as expected or wrong?
I can't seem to be able to reproduce with trunk.
>the event coordinates of the button press event are wrong This does happen in IRC that the terminal window will scroll before the context menu appears. So I finally managed to build and install intltool-0.40 (checkinstall ftw), but gnome-terminal trunk doesn't pop up any contextual menus at all. Do I need to run it outside of the src directory it got built in? This is trunk as of yesterday.
Well so what must happen is that you think you click on the URL, but actually just 1 nanosecond before the click registers the terminal has scrolled and thus the click goes to the new line under the mouse pointer, which has no URL. The fact that the popup has a delay in appearing has nothing to do with this. (Did you "make install"? Any warnings on console when starting "gnome-terminal --disable-factory" ?)
Ping? Can you still repro this in g-t 2.24.0 ?
I'm using gnome-terminal 2.24 on Ubuntu Intrepid. After renicing gnome-terminal to +10 and starting two cat /dev/urandom | gzip | uuencode - processes (to waste CPU resources), I was able to get the context menu to open after I moved the mouse cursor away from the URL. "Open link" still appeared in the context menu and behaved appropriately. So, no, this bug is not reproducible with 2.24