GNOME Bugzilla – Bug 310814
consistent behaviour with click/enter + modifiers
Last modified: 2018-08-03 19:14:21 UTC
Middle click and Shift+middle click currently both open a link in a new tab. Since we offer 'new tab' and 'new window' in menus it would be a good idea to map 'new window' to Shift+middle click.
From http://mail.gnome.org/archives/epiphany-list/2005-July/msg00048.html : In the Mozilla suite, Safari, MSIE/Mac, and (to some extent) Firefox, but not Epiphany, modifier keys do the same thing for the Go button, for Enter while in the address field, for clicking on links, for clicking on bookmarks (not shown in the following table because it's identical to clicking on links), and for pressing Enter while a link is focused. Go button Enter in click link Enter on address field focused link --------------------------------------------------------------------- Unmodified open URL open URL open link open link Command/Ctrl+ open URL in open URL in open link in open link in new window new window new window new window Shift+Ctrl+ open URL in open URL in open link in open link in new window new window new window new window behind the behind the behind the behind the current one current one current one current one Option/Alt+ download download download download URL URL linked item linked item In Firefox this consistency is disrupted because the Command+ and Shift +Command+ commands are reversed by default, *only for links* and not for bookmarks, and apply to tabs, rather than windows; and Option+ in the address field opens a new tab instead of downloading the URL. (I think Ctrl+Enter in the address field may add "www." and ".com" in Firefox for Windows, but I don't have Windows here to check.) Safari does the same thing with Command+ and Shift+Command+ as Firefox if tabs are turned on, unless the "Select new tabs as they are created" option is turned on. ---- Note: one complication is that Alt-clicks are stolen by metacity in the default configuration.
*** Bug 148319 has been marked as a duplicate of this bug. ***
The table from comment 1 does not include any actions that open a new tab. I would favour a mapping where middle click (equivalent to row #2, Ctrl+ something) would open a new tab, and Shift+Ctrl (row #3) would open a new window. I don't see much use for opening windows behind the current one.
Bug 306683 is relevant to this bug.
About opening new tabs -- when tabs are turned on in Safari, Command+ and Shift+Command+ open items in new tabs, and the modifiers for opening items in new windows are changed to Option+Command+ and Option+Shift+Command+. Watch how the help text changes in the following screenshots.
Created attachment 58347 [details] with tabs turned off
Created attachment 58349 [details] with tabs turned on and "Select new tabs as they are created" turned off
Created attachment 58350 [details] with tabs turned on and "Select new tabs as they are created" turned on
The shift/ctrl handling of opening links in new tab/window should be consistent now in 1.9.7 unless I overlooked some places where this needs to be handled.
Mass changing target 2.16 -> 2.18
I think Bruno Boaventura submitted a patch for fixing buttons and middle clicks, besides that I don't think Ephy has inconsistencies. Objections?
Diego: can you give a bug number? How are buttons and middle clicks "fixed" by the patch, exactly? I note that Ctrl+Enter in the address bar currently opens the selected URL or bookmark in a new tab, and think this is a more desired behaviour than opening in a new window, especially because of the somewhat controversial focus-in-address-bar behaviour Epiphany has.
Bruno was trying to solve bug #362591
Moving to 2.20 target due to feature and UI freeze for 2.18.
Hmmm, isn't this already fixed?. I don't see any problems as of now.
As pointed out on epiphany-list today, middle clicking bookmarks in the bme does nothing.
Just expanding Reinout van Schouwen's last comment: "Is there any good reason why I have to remember to use the mouse scroll button to open a URL in a new tab when I click on it in the Menu bar 'Bookmarks' while I also have to remember to use the right click => context menu => left click => open in new tab, when using the Bookmarks Editor. Shouldn't a mouse scroll click work for both."
Are any other changes desired here?
(In reply to Michael Catanzaro from comment #18) > Are any other changes desired here? In https://bugzilla.gnome.org/show_bug.cgi?id=740618#c7 you said 'Feel free to open another bug for this' (being Alt+click for download). I think this bug already covers that?
I'm cool with changing our shortcuts to be more consistent and/or to match other browsers, but what specific changes are requested here? The table in comment #1 was written for a world in which browsers didn't have tabs. And the suggestion in bug #740618 comment 3 is based on a very old webpage that no longer accurately reflects Firefox shortcuts (e.g. Alt+click no longer starts a download).
(In reply to Michael Catanzaro from comment #20) > I'm cool with changing our shortcuts to be more consistent and/or to match > other browsers, but what specific changes are requested here? The table in > comment #1 was written for a world in which browsers didn't have tabs. And > the suggestion in bug #740618 comment 3 is based on a very old webpage that > no longer accurately reflects Firefox shortcuts (e.g. Alt+click no longer > starts a download). Ah. Hmm. It does in Chromium, though. For the purposes of this bug, I think only the Alt modifiers are still relevant. The small nugget in comment 3 "Note: one complication is that Alt-clicks are stolen by metacity in the default configuration" could explain why this wasn't done in the Gnome 2.x era already.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/epiphany/issues/104.