Comment 1 for bug 707024

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 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