GNOME Bugzilla – Bug 740618
On Flickr organizer: selecting a range of pictures from the lower bar by using Shift and click downloads the last clicked picture and doesn't multiselect
Last modified: 2017-08-07 11:25:36 UTC
WKGTK 2.6.4 (also previous versions) and Epiphany 3.14.1. Logged in in Flickr and in the organizer, select more than one picture from the lower bar by clicking in the first and, then, clicking on the last picture of the range while pressing Shift. The last clicked picture miniature is downloaded and the multiselection is not performed. This is also reproducible by individual multiselection using the Ctrl key. This is a specific bug in Epiphany as it seems to work correctly using MiniBrowser.
(In reply to comment #0) > This is a specific bug in Epiphany as it seems to work correctly using > MiniBrowser. My first guess is that the Shift+Click=download feature overrides any custom javascript functionality.
(In reply to Reinout van Schouwen from comment #1) > My first guess is that the Shift+Click=download feature overrides any custom > javascript functionality. Seems like in other browsers, Shift+click is open in new window. There might be more benefit in matching other browsers here than in keeping the Shift+click shortcut. What do you think, Reinout? Anyway, it indeed seems like a likely culprit. First thing to do is to confirm. Andres, since you build Epiphany yourself, could you please open up ephy-window.c, search for ephy_window_connect_active_embed(), and in that function comment out these lines: g_signal_connect_object (view, "button-press-event", G_CALLBACK (ephy_window_dom_mouse_click_cb), window, 0); Then go to decide_policy_cb() in the same file. Comment out this code: /* Because we connect to button-press-event *after* * (G_CONNECT_AFTER) we need to prevent WebKit from browsing to * a link when you shift+click it. Otherwise when you * shift+click a link to download it you would also be taken to * the link destination. */ else if (button == 1 && state == GDK_SHIFT_MASK) { webkit_policy_decision_ignore (decision); return TRUE; } Does Flickr work properly with both of those removed? If so, does it work properly with just one or the other block removed?
According to the overview on http://dmcritchie.mvps.org/firefox/keyboard.htm most browsers nowadays use Shift+Click for opening in new window, and Alt+Click for downloading the link. I see no harm in following that convention.
(In reply to Michael Catanzaro from comment #2) > Does Flickr work properly with both of those removed? Yes, it does. > If so, does it work properly with just one or the other block removed? Both need to be commented to work properly.
(In reply to Andres Gomez from comment #4) > (In reply to Michael Catanzaro from comment #2) > > Does Flickr work properly with both of those removed? > > Yes, it does. > > > If so, does it work properly with just one or the other block removed? > > Both need to be commented to work properly. Sorry, I messed with this. It seems only the patch for ephy_window_connect_active_embed() is really needed. Tested with Ephy 3.20.6 and WKGTK+ 2.15.3
(In reply to Reinout van Schouwen from comment #3) > According to the overview on http://dmcritchie.mvps.org/firefox/keyboard.htm > most browsers nowadays use Shift+Click for opening in new window, and > Alt+Click for downloading the link. I see no harm in following that > convention. Good idea, but then we still have the same problem. We ideally need to figure out how to handle the mouse press event only if WebKit doesn't.
Andres, I'm pushing a commit that fixes the attached testcase that I stole from w3schools and modified. I think it will fix Flickr but please test to be sure and reopen if it doesn't. (In reply to Reinout van Schouwen from comment #3) > According to the overview on http://dmcritchie.mvps.org/firefox/keyboard.htm > most browsers nowadays use Shift+Click for opening in new window, and > Alt+Click for downloading the link. I see no harm in following that > convention. Feel free to open another bug for this.
Note: this is aligning our behavior with Chrome, which allows websites to cancel mouse events. Firefox does not allow this. (I'm not sure how the Flickr organizer could work properly in Firefox.) Epiphany previously allowed websites to cancel mouse events *except* for the shift+click to download shortcut, which does not make sense.
Created attachment 344079 [details] test html
The following fix has been pushed: 3bbe717 window: allow websites to handle shift+click events
Created attachment 344080 [details] [review] window: allow websites to handle shift+click events Currently we allow websites to cancel all mouse events EXCEPT shift+click -> download page. This doesn't make much sense and there's no technical reason it has to be this way, so handle it the same way we do other shortcuts instead, when handling navigation policy decisions, rather than intercepting the event before it even reaches WebKit.