Development:Planning:Shift Toggle
Camino has a "load in background" pref to control whether new tabs/windows spawned in various ways load in the backgroud or foreground. In addition, the shift key acts as a toggle, causing the tabs/windows to be opened in the opposite state from the pref.
(In many cases, holding down Cmd while selecting or dragging an item will cause it to open in a new tab/window, just like Cmd-clicking a link. In some cases, this key is a prerequisite for the "load in background" pref and its shift toggle to work.
- Note that this behavior is “broken-ish” right now; Bug 333765 - Opening a bookmark in a new tab no longer works when pushing Command after opening a bookmark folder, only before.
- Also, due to limitations of alternates, command will only work as a "open in new" toggle for menu items without existing shortcuts)
Contents
Actions that need to respect the background pref and shift toggle
Menus
- Selecting "View Page Source" from the View menu (
only when cmd is held downum, no; it is always new window or new tab)- Bug 331839 - View Source menu command does not respect shift modifier
- Selecting a Go menu item [Global History] (only when cmd is held down)
- pref: Yes [only when held down before opening menu]
- toggle: No
- Bug 350806 - Make Go menu history items respect the cmd/shift modifiers properly
- Selecting "Home" from the Go menu (only when cmd is held down)
- Doesn't respect command
- Selecting "Back" from the Go menu (only when cmd is held down)
- Doesn't respect command
- Selecting "Forward" from the Go menu (only when cmd is held down)
- Doesn't respect command
- The above 3 will never respect command, the latter because of Gecko and the former due to limitations of alternates
- Selecting an item from the Local Nework Services submenu (only when cmd is held down)
- unknown
- the "About Local Network Services" item always opens in a new tab/window regardless, and in the foreground
- Selecting a Bookmarks menu item (when cmd is held down, to open in new foo)
- pref: Yes
- toggle: Yes
- Selecting "Open in Tabs" in the Bookmarks menu (only when cmd is held down)
- pref: Yes
- toggle: No
- Back and Forward button menus
- does not respect cmd
- can't test in nightlies because of Bug 333765 and because holding cmd triggers toolbar drag
- does not respect cmd
- Selecting a Bookmark Bar folder menu item (when cmd is held down, to open in new foo)
- pref: Yes
- toggle: Yes
- Selecting "Open in Tabs" in Bookmark Bar folder menus (only when cmd is held down)
- pref: Yes
- toggle: No
Context Menus
- Open Link in New Window/New Tab in the context menu
- pref: Yes
- toggle: No
- View image (when cmd is held down) in the context menu
- pref: Yes
- toggle: Yes
- Search (when cmd is held down) in the context menu
- Bug 331670 - "Search" CM item needs to respect new & background keys/toggles
- Back and Forward in the context menu (when cmd is held down)
- Doesn't respect command
- Open in New Tab/Window in the Bookmarks CM (manager)
- pref: Yes
- toggle: Yes
- Open in New Tab/Window in the History CM (manager)
- pref: Yes
- toggle: No
Selection
- Cmd-clicking single/multiple Bookmarks items in the Manager
- pref: Yes
- toggle: Yes
- Cmd-clicking single/multiple History items in the Manager
- pref: Yes
- toggle: No
Cmd-clicking multiple items has varying degrees of success, based on interaction between outliner/list view meaning of shift and cmd (expand selection) and Camino usages for "new foo" and "toggle fg/bg pref"; they seem to work OK here when not extending the selection, but see Bug 285182 for more (bugs when trying to extend the selection).
Text Entry
- Cmd-return in location bar
- pref: Yes
- toggle: Yes
- Cmd-return in search bar
- pref: Yes
- toggle: Yes
Content area
- Cmd-return or cmd-enter with a link selected in the content area (Bug 164863)
- pref: no
- toggle: no
Toolbars
Main Toolbar
- View Source Toolbar Button
- pref: No (has own pref)
- toggle: Yes
Bookmark Bar
- Cmd-clicking a tab group
- pref: Yes
- toggle: No
- NOT clicking a tab group (See Discussion)
- Cmd-clicking a Bookmark Bar item
- pref: Yes
- toggle: Yes
Tab bar
- NOT double-clicking to create a new tab (See Discussion)
Dragging to the tab bar
Anything dragged to the blank area of the tab bar should open new tabs, respecting both the pref and the shift key.
- Dragging a tab group to the tab bar
- Bug 319627 - Cmd-drag a bookmark folder should append, not replace
- Dragging a bookmark folder to the tab bar
- Bug 319627 - Cmd-drag a bookmark folder should append, not replace
- Dragging a Bookmark Bar item to the tab bar
- Bug 320668 - Dragging a bookmark into the tab bar creates a background tab, regardless of pref
- Dragging a link on a page to the tab bar
- Bug 183401 - Bring target tab to front on link drop, based on tab load-in-background setting
- Dragging a plain-text link to the tab bar
- pref: No
- toggle: No
- Dragging URL text from the location bar to the tab bar
- pref: No
- toggle: No
- Dragging a favicon from a tab or the location bar to the tab bar
- pref: No
- toggle: No
- Dragging one *loc to the tab bar
- pref: No
- toggle: No
- Dragging multiple *locs to the tab bar
- pref: No
- toggle: No
The fix for Bug 320668 will almost certainly fix the above
Dragging to an existing tab
We need foreground/background distinctions here. Dragging to the current tab should have the same behaviour as dragging to the content area, so even Cmd is held it should load in the same tab. Dragging to a background tab should be equal to dragging to the tab bar.
- Dragging a tab group to an existing tab
- Bug 319627 - Cmd-drag a bookmark folder should append, not replace
- Dragging a bookmark folder to an existing tab
- Bug 319627 - Cmd-drag a bookmark folder should append, not replace
- Dragging a Bookmark Bar item to an existing tab
- Dragging a link on a page to an existing tab
- Dragging a plain-text link to an existing tab
- Dragging URL text from the location bar to an existing tab
- Dragging a favicon from a tab or the location bar to an existing tab
- Dragging one *loc to an existing tab
- Dragging multiple *locs to an existing tab
The fix for Bug 320668 will almost certainly fix the above
See also Bug 339404 - Drag and drop of a folder or tab group onto an existing tab replaces from beginning, not from drag target location
Dragging to the content area and current tab
- Dragging a tab group to the content area
- Dragging a bookmark folder to the content area
- The behavior of the above three are an odd case. We should always open everything we're asked to open somehow.
- Dragging multiple *locs to the content area
- Bug 173658 - Dragging two webloc files to content area, only one opens
- Replace the content of the dragged-to tab, keep it focused, and append any additional bookmarks (neither the cmd-for-new shortcut nor the load-in-bg pref/toggle)
- If you wanted to append (or load in bg), you could drag to the empty space or the overflow widget; you are specificly dragging to the active tab and want to see that website NOW.
- We shouldn't replace other tabs because the user can't see them; append instead
- NO other drags to the content area should respect pref or toggle (See Discussion)
To Do
- Seek reviews to see if any actions are missing
- Determine if any do not make sense on this list, if any
- Determine
- which of these work
- which of these do not, but are covered by existing bugs (and link to bugs)
- which need to be filed (then link, once filed)