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.

Actions that need to respect the background pref and shift toggle

Menus

• Selecting a Bookmarks menu item (when cmd is held down, to open in new foo)
  • pref: Yes
  • toggle: Yes
• Selecting a Go menu item (only when cmd is held down)
  • pref: Yes
  • toggle: No
• Selecting "Open in Tabs" in the Bookmarks menu (only when cmd is held down)
  • pref: Yes
  • toggle: No
• 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 Menu

• 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

Toolbar

• 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
• View Source Toolbar Button
  • pref: No (has own pref)
  • toggle: Yes
• NOT double-clicking to create a new tab (See [User_talk:Sardisson/Shift_Toggle|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

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

  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 [User_talk:Sardisson/Shift_Toggle|Discussion]])

To Do

1. Seek reviews to see if any actions are missing
2. Determine if any do not make sense on this list, if any
3. 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)