I'm working on a patch that will make middle-click, alt, shift, ctrl, and ctrl+shift work on link-like controls throughout Firefox's UI. Right now, each of those modifiers works in some places but not in others. My patch will also make all link-like controls focus the content area as they load a URL.

Exactly what will change with this patch? What modifiers are used and where?

Ctrl new tab, selected Shift new window Ctrl+Shift new tab, in background Alt save You can swap Ctrl and Ctrl+shift by toggling the hidden pref browser.tabs.loadBookmarksInBackground (not browser.tabs.loadInBackground). Middle-clicking is the same as Ctrl+clicking (it opens a new tab) and it is subject to the shift modifier and pref in the same way. When I'm done, hopefully the modifiers and middle-clicking will work in the following places, with a few exceptions: Moz# Fx# 72361 236864 bookmarks menu (ctrl+shift opened a new window) 89922 bookmarks in sidebar (ctrl+shift opened a new window) history sidebar (ctrl+shift opened a new window) 93034 throbber 214816 go menu: sites 224132 "view image", "view background image" context menu items help > release notes middle-click paste (Linux) items in the back and forward menus 75731 202819 back, forward buttons (without copying history) go menu: back, forward 164008 address bar history address bar autocomplete 198028 go button dragging to address bar 233411 dragging to search bar "Search Web for ..." context menu item enter in search bar (parity-GoogleToolbarForIE) home button (at least when there's only one home page) So far, I have the first ten working (through the break in the list), but with some bugs: middle-clicking some things doesn't work unless you left-click them first (due to bug 246720), and the back and forward buttons always appear enabled. I'm still thinking about whether to do the reload button (Ctrl+reload would open the current page in a new tab). Shift+reload has a special meaning dating back to Netscape 4, which I don't want to change.

(In reply to comment #2) > Ctrl new tab, selected > Shift new window > Ctrl+Shift new tab, in background > Alt save The default for Firefox is to load tabs in the background, so Ctrl should not spawn a new selected tab, and Ctrl+Shift should not spawn a background tab; it should be the other way around. Maybe that's what you meant?

I'm going for consistency with bookmarks (bug 236864). I does make sense in a way: the main reason anyone wants tab to load in the background is so opening links from web pages doesn't interfere with reading or clicking more links. When you're opening links from other places, that reason doesn't make sense. Anyway, once my patch is in, it will be easier to change than it is now :)

How about form submission buttons? There is, as far as I know, no way to see the results of submitting a form in a new tab while keeping the form visible.

I'm not going to fix form submission buttons because that would require backend work. See bug 17754.

(In reply to comment #2) > home button (at least when there's only one home page) Bug 232172 already covers that. My patch for that also works with multiple home pages. It doesn't respect the pref browser.tabs.loadBookmarksInBackground yet though.

This patch: * Makes middle-click, shift+click, ctrl+click, and ctrl+shift+click work consistently in many places in Firefox's UI. * Puts focus in the content area after you left-click Go menu items, etc. * Makes all UI links follow the hidden pref "open bookmarks in background". * Makes mailto: bookmarks work. (Before, they said "mailto: is not a registered protocol. I don't know why.) It makes the modifiers work in: 72361 236864 bookmarks menu (ctrl+shift opened a new window) 89922 bookmarks in sidebar (ctrl+shift opened a new window) history sidebar (ctrl+shift opened a new window) 93034 throbber 214816 go menu: sites 224132 "view image", "view background image" context menu items help > release notes middle-click paste (Linux) items in the back and forward menus 75731 202819 back, forward buttons (without copying history) go menu: back, forward This patch needs to be tested on Mac and Linux to make sure I got the modifiers right on those platforms. On Linux, the "middle-click paste to load URL" feature needs to be tested with various things in the clipboard and with various modifiers.

Improvements from previous patch: * Now includes a port of the patch from bug 217090, since I needed that to test middlemouse.contentLoadURL on Windows. This change only affects non-Linux users who have middlemouse.contentLoadURL set to true. * No longer breaks middle click paste to load URLs (typo fix). * Slightly better comments.

I guess an "onmiddleclick" event handler would be handy here.

Comment on attachment 151042 [details] [diff] [review] better patch >--- base/content/browser-context.inc 10 Apr 2004 05:04:09 -0000 1.4 >+++ base/content/browser-context.inc 17 Jun 2004 19:26:05 -0000 >@@ -132,7 +133,8 @@ > <menuitem id="context-viewbgimage" > label="&viewBGImageCmd.label;" > accesskey="&viewBGImageCmd.accesskey;" >- oncommand="gContextMenu.viewBGImage();"/> >+ oncommand="gContextMenu.viewBGImage(event);" >+ onclick="if(event.button==1) { eval(this.getAttribute('oncommand')); event.target.parentNode.hidePopup(); }"/> > <menuitem id="context-undo" > label="&undoCmd.label;" > accesskey="&undoCmd.accesskey;" >--- base/content/browser-menubar.inc 7 Jun 2004 08:16:53 -0000 1.24 >+++ base/content/browser-menubar.inc 17 Jun 2004 19:26:05 -0000 >@@ -268,10 +268,30 @@ > </menupopup> > </menu> > >- <menu label="&goMenu.label;" accesskey="&goMenu.accesskey;" oncommand="var url = event.target.getAttribute('statustext'); if (url) openTopWin(url);"> >+ <menu label="&goMenu.label;" accesskey="&goMenu.accesskey;" >+ oncommand="var url = event.target.getAttribute('statustext'); if (url) openUILink(url, event, false, true);" >+ onclick="if(event.button==1) { event.target.parentNode.hidePopup(); eval(this.getAttribute('oncommand')); }"> >+ Just for sanity, try to be consistent about the order of running oncommand and hiding the popup, unless there's a reason for the difference. Maybe this should all be factored out into a function, since it's repeated so much? Looks good to me other than that.

I added a function "checkForMiddleClick" to utilityOverlay.js.

aebrahim tested the patch on Linux for me. Now I know that it works correctly on Windows and Linux :)

Comment on attachment 151194 [details] [diff] [review] patch addressing bryner's review comments Looks good.

Fix checked in 2004-06-23 15:54 PST.

Patch checked in on AVIARY_1_0_20040515_BRANCH too. I had to apply the last hunk (removing the old version of OpenURL in history.js) manually; I don't know why.

How about modifiers on Javascript links and such? Is it possible to detect link.open() in Javascript and apply the link modifier in such case? If it works, then pages such as Hotmail will work flawlessly.

Cheng: that's bug 55696 or bug 138198.

*** Bug 250086 has been marked as a duplicate of this bug. ***

*** Bug 251189 has been marked as a duplicate of this bug. ***

*** Bug 255299 has been marked as a duplicate of this bug. ***

What about URL bar dropdown, Go button, URL bar ctrl+enter and search bar ctrl+click (bug 198028, bug 64008, bug 162119 and ?)? Also, middle-click on bookmark doesn't respect open-in-the-background pref.

Did, at any point, a checkin from the bug make ctrl-click/middle-click on reload open it in a new tab? This was working for me at one point, I just don't recall if it was thanks to an extension. If it was innate to Firefox, it has recently regressed. Please bring it back! No use in having a middle click on that button do absolutely nothing, and I found reloading the current page in a new tab often very useful. ("Compare this old version of this page to the current version" great for news articles, web development, network monitors... anything that changes).

> What about URL bar dropdown, Go button, URL bar ctrl+enter and search bar > ctrl+click (bug 198028, bug 64008, bug 162119 and ?)? I skipped things related to the address and search field because they're weird (alt instead of ctrl for new tab). File a bug :) > Also, middle-click on bookmark doesn't respect open-in-the-background pref. The pref for bookmarks is separate from the pref for links. This will be more clear in Firefox 1.0 Preview Release, and you'll be able to toggle both prefs. > Did, at any point, a checkin from the bug make ctrl-click/middle-click on > reload open it in a new tab? No. That would be trickier to implement because it would require getting a new version of the page, possibly copying POSTDATA, etc. File a bug :)

I know this bug is closed, but why not swap the SHIFT and ALT behaviours? SHIFT-click for saving has been the behaviour for ages. Changing this for ALT can be counter intuitive for many users.

*** Bug 261164 has been marked as a duplicate of this bug. ***

See also: bug 263942, bug 279687.

Comment on attachment 151194 [details] [diff] [review] patch addressing bryner's review comments >+function whereToOpenLink( e, ignoreButton, ignoreAlt ) >+{ >+ if (e == null) >+ e = { shiftKey:false, ctrlKey:false, metaKey:false, altKey:false, button:0 }; >+ >+ var shift = e.shiftKey; >+ var ctrl = e.ctrlKey; >+ var meta = e.metaKey; >+ var alt = e.altKey && !ignoreAlt; >+ >+ // ignoreButton allows "middle-click paste" to use function without always opening in a new window. >+ var middle = !ignoreButton && e.button == 1; >+ var middleUsesTabs = getBoolPref("browser.tabs.opentabfor.middleclick", true); >- getBrowserTargetFromEvent: function (aEvent) >- { >- var button = (aEvent.type == "command" || aEvent.type == "keypress") ? 0 :aEvent.button; getBrowserTargetFromEvent used to check that the event has a button. whereToOpenLink does not...

Does that cause problems, such as incorrect behavior or javascript strict warnings?