Middle-click on LINKs "sometimes" is treated as Left-click

[Michael Moroni]

As per description. But to be more specific on the "sometimes" part: this almost always happens while I try to middle-click open a link while midori is busy. For instance, if I am at a forum or deviantArt, and I try opening muliple links with middle-click, sometimes the browser seems to "stall" a second or so, and then the last clicked link opens in the CURRENT tab, as if it was left-clicked instead.

This bug has been in placed since a long time ago, but just now I've been annoyed enough to report it.

NOTE: This doesn't happen when I hold down Ctrl and left click all over the place (assuming I don't release Ctrl while Midori "stalls"). Are middle-clicks being handled by simulating a Ctrl+Click, by any chance? :/

Moved from FS: http://www.twotoasts.de/bugs/index.php?do=details&task_id=1029

[Michael Moroni (airon90)]

I've done some debugging, and I believe I understand better what is happening. This is in part a bug in webkit, but it can be solved within Midori's code.

The relevant section is in gtk_widget_button_press_event_cb (midori-view.c). What happens is that while webkit is busy rendering/whatever the background, the url is not retrieved on the callback, so link_uri = midori_view_get_link_uri(view); returns null. However, when a click CB goes through without being handled, it is again raised to let webkit handle it directly. When webkit handles the middle-click by itself, it DOES recognize the URL, and then it is opened on the current tab (probably because webkit itself has no notion of tabs, so left/middle clicks both open URLs in the current view).

One possible solution is to add a "return TRUE;" when handling middle-clicks to avoid webkit handling them itself. The bug would then become "some middle clicks do nothing while Midori is busy/stalling", but I consider it a better situation than having a middle-click open the link in the current tab.

So, to reiterate, the summarized version:
1. User middle-clicks on a link while webkit is stalling/busy
2. No URL selection is detected in gtk_widget_button_press_event_cb
3. The click event is propagated to webkit
4. Webkit does sees the selected URL, and loads the link on the same view/tab.

I tracked down the source of the bug. The problem is that midori_view_ensure_link_uri is using the (x,y) coordinates of the current location of the pointer, not the coordinates of the GdkEvent object (hence there is a mismatch and unproper parsing when the mouse changed locations while Midori was stalling).

The attached patch solves this issue (applicable to Midori 0.2.9)

wallex?field.comment=I've done some debugging, and I believe I understand better what is happening. This is in part a bug in webkit, but it can be solved within Midori's code.

The relevant section is in gtk_widget_button_press_event_cb (midori-view.c). What happens is that while webkit is busy rendering/whatever the background, the url is not retrieved on the callback, so link_uri = midori_view_get_link_uri(view); returns null. However, when a click CB goes through without being handled, it is again raised to let webkit handle it directly. When webkit handles the middle-click by itself, it DOES recognize the URL, and then it is opened on the current tab (probably because webkit itself has no notion of tabs, so left/middle clicks both open URLs in the current view).

One possible solution is to add a "return TRUE;" when handling middle-clicks to avoid webkit handling them itself. The bug would then become "some middle clicks do nothing while Midori is busy/stalling", but I consider it a better situation than having a middle-click open the link in the current tab.

So, to reiterate, the summarized version:
1. User middle-clicks on a link while webkit is stalling/busy
2. No URL selection is detected in gtk_widget_button_press_event_cb
3. The click event is propagated to webkit
4. Webkit does sees the selected URL, and loads the link on the same view/tab.

I tracked down the source of the bug. The problem is that midori_view_ensure_link_uri is usi...

[Michael Moroni (airon90)]

Just to clarify that this happens only if you set the option 'Open tabs in background'

Test the patch and I have the same results..

Please. Stop using midori with this bug.:(

msdelos

[Michael Moroni (airon90)]

Hmm, the same bug as described here, it isn't fixed by this patch? For me it works now right. On second thought it might not be the best idea to block middle-clicks that are unparsed rather than forwarding them to webkit, after all, I am guessing middle-click pasting would break if we did that.

However, the patch posted here IS still needed. The fact that Midori will use the current mouse position rather than the coordinates of the XEvent IS a bug.

wallex

[Michael Moroni (airon90)]

My apologies for looking into this late, unfortunately the bug notifications are not always good at attracting my attention. To add to it, I can't reliably reproduce this issue although I have seen it.

After some testing a patch similar to the above was committed, the code changed a bit in master. It looks like it improves the issue, although it's not fully solved, thus I set the status to 'Requires research'.

kalikiana

[Mats Rauhala (mats-rauhala)]

I can reproduce this every time. What information would you need to solve it, I'm willing to cooperate.

[Cassidy James Blaede (cassidyjames)]

Just dropping by to say that I've seen this bug quite a bit, especially when writing for the elementary Journal (I've lost many an incomplete article due to links opening in the current tab rather than in a separate tab). I'd love to test anything you throw at me. :)

[gue5t gue5t (gue5t)]

I've done some research into this and I think it might be possible that the reason this occurs is that webkit's default button handling opens links on button-release, while all the midori button-handling is on button-press. In my experience with this bug's behavior, this seems to be confirmed: the new tab opens first (in the background per my personal settings) when midori itself opens it for middle-click. But when the click is released a fraction of a second later, webkit picks up on it and decides to open the page in the current tab (try GtkLauncher; release of /any/ mouse button on a link will open it). I have attached a patch but since this bug is so hard to reproduce consistently I don't know for sure if this analysis/fix is correct. Review would be greatly appreciated.

[Cris Dywan (kalikiana)]

From what I can say, I used to occasionally see this on openSUSE 11.4 but never on Ubuntu 11.10, so it kinda seems like a bug to start with.
Based on gue5t's hypothesis, I added a variable button_pressed_handled, that is used for the return value in button_release. That feels cleaner to me than hardcoding a TRUE there. However, as I mentioned, I'm unable to reproduce the bug.