Firefox/Projects/Tab Matches in Awesomebar: Difference between revisions
Jump to navigation
Jump to search
(Add status block) |
|||
| Line 17: | Line 17: | ||
= Current Status = | = Current Status = | ||
<onlyinclude>Main patch needs final review, gavin.</onlyinclude> | <onlyinclude>Main patch ({{bug|480350}}) needs final review, gavin.</onlyinclude> | ||
= Goals / Use Cases = | = Goals / Use Cases = | ||
Revision as of 16:08, 5 February 2010
|
RESTRICTED |
|
| Please do not edit this page without permission; comments should be added to the discussion page. |
Overview
Sprint lead: limi
Sprinters: bmcbride, limi, ashughes (QA)
- Description
- When an awesomebar result matches the URL of an already open tab, it should indicate that and allow the user to switch to that tab instead of duplicating it.
- Aza has some suggestions
- So does Madhava
- Boriss is interested (& happy to give unsolicited opinions)
- Limi wants to drive this for 3.7, blog post with some suggested changes
Try server builds are available at http://people.mozilla.org/~bmcbride/tabmatches/latest/
Current Status
Main patch (bug 480350) needs final review, gavin.
Goals / Use Cases
- Reduce the number of unintentionally created duplicate tabs in the users large tab set
- Allow users to create duplicate tabs if they actually intend to have duplicates
- Allow users to search for specific tabs, which should be faster than a browser operation with the all tabs control, and is fully integrated into our central UI for searching, the awesome bar (as oppose to creating another field).
Non-goals
- Promote tab searching over other types of revisitation (for instance placing all of the tab results on top)
- Overly complicate the current design of the awesome bar (through things like the introduction of additional icons, arrows, or moving the focus right/left in addition to up/down)
Bugs
Design
Limi's follow-up blog post with some suggested changes