Find bar usability issues

The find bar has some usability/UI issues that need to be thought through.

• Per-tab versus per-window
  • Current bar is per-window
    • Matches appearance of bar, which looks like a part of the main window rather than a part of the tab
    • Allows for finding the same text on various tabs when you don't know what tab something is in or have several tabs open on the same "topic"
    • If I have the red background "no match" and change to a page where that text _can_ be found on the page, what should happen?
  • Old Seamonkey FAYT was per-tab
    • Fit well with goal of fast page navigation and minimal UI
    • In general, per-tab allows for repeated searching of topics without having use of other tabs "interfere"
  • Overall, desired implementation depends on what we believe browser and find usage looks like
    • If tabs are mostly discrete pages with little connection to each other in the sense of whatever task the user is accomplishing, per-tab finding makes more sense and is less irritating as the user switches between pages
    • If users wish to search across many tabs, per-window requires less UI interaction and may be less annoying
    • Do we have good data on how users react to current implementation?

• Selection
  • Find bar collapses selection when it's raised, making it hard to see where you were going to start searching
  • Use case: I want to "search for this text in the page" - I highlight the text, now have to copy, ctrl-f, paste into bar
  • Proposal: On find bar raise, if text is selected, do not collapse; instead, copy this text into the find bar and immediately do a search on it (changes selected text color to the ATTENTION color of a find match). This makes it obvious you're currently searching for that text and where the next match will occur [i.e. after the selected text].
    • Pros: Solves both issues above
    • Cons: changes existing find bar contents (what if you wanted to do another search for your previous term after selecting some text?)
  • Alternate proposals: Just don't collapse selection, Don't collapse + copy selected text to find bar but don't search, make first proposal available through context menu entry "Find in this page..."
    • Pros: Less intrusive if above behavior is deemed too bizarre, doesn't necessarily clear previous search term
    • Cons: Context menus suck, may not go far enough

• Highlighting
  • Highlighting behavior needs to match finding behavior w.r.t. per-tab versus per-window
    • Proposal: When changing tabs, unhighlight on the old tab, and highlight on the new tab
      • Pros: Makes highlighting do sane things on tab switch, follows behavior of Google toolbar
      • Cons: Can make tab switching slower
  • Highlighting shouldn't change the DOM
    • Proposal: Reimplement highlighting using a new selection (like the spellchecker does) instead of crawling the DOM
      • Pros: Faster, doesn't modify page
      • Cons: Can't print out highlights anymore (maybe this is a pro?)
  • Highlighting color could/should be user-configurable, based on system colors, support multiple colors, guarantee visibility on the current page, ...?
  • Highlighting maybe should stop when the find bar is closed?

• Case sensitivity
  • "Match case" button takes up extra space for a not-frequently-used feature
  • Often a case-sensitivity is desired for a single search, not permanently
  • Proposal: Remove button, do something like emacs for case sensitivity (do case-insensitive searches for lowercase strings, automatically change to case-sensitive searching when uppercase is typed)
    • Pros: Hopefully "just does the right thing" without user interaction, solves both issues above
    • Cons: Case sensitivity is less discoverable, might be confusing, hard to case-sensitive search for all lowercase
  • Alternate Proposal: Make "Match case" checkbox reset when find bar is dismissed
    • Pros: Solves "I forgot I had it on" problem
    • Cons: UI still bloated, automatic box clearing mey be unexpected/irritating