183998 - Make typeaheadfind work in mailnews (only manually)

Status: VERIFIED FIXED

(SeaMonkey :: Find In Page, enhancement, P2)

Description

[Aaron Leventhal]

Allow the user to manually start typeaheadfind in mailnews.

The accelerators would be the same that we're currently using in the browser.

/ to start text search
' to start link search

Comment 1

[Aaron Leventhal]

Unforunately / collides with collapse all threads in mailnews.

I suggest that we should change the collapse all threads accelerator to \ instead
And use / for text search.

Comment 2

[sairuh (rarely reading bugmail)]

this could be really nifty --however, where would TAF apply? which pane in the
mailnews 3pane, all of them, or just the message pane? what other windows would
use this feature, the mail standalone, addressbk...others?

side note: i noticed that when i had a standalone frontmost, that the
single-letter commands (M for mark, N for next unread, etc) took precedence. (at
least with a trunk build on linux rh7.2.)

Comment 3

[Aaron Leventhal]

Typeaheadfind only works in content windows, so it would only work in the
message pane.

Comment 4

[Aaron Leventhal]

Should we put these items in the mailnews edit menu?

Find links as you type     '
Find text as you type      /

I'm concerned that will make too many find-related items in the edit menu.

Comment 5

[sairuh (rarely reading bugmail)]

yeah, it might crowd things. i'm not inclined to have these items in the
mailnews Edit menu --since they're not (currently) in the browser Edit menu either.

Comment 6

[Owen Marshall (Not reading bugmail)]

Typeahead documentation and QA now have a link to this bug.

My $0.02 - Aw man, more testcases to write =P

No, this sounds like a very good idea. As far as commands and whatnot, `\`
should probably be changed. It only applies to the news component -- a
subcomponent of the mailnews component. `/` applies to the browser (and mailnews
, if this bug is fixed)

Ok, here is an idea. (remember that I am quite new to C++, so this may mean
nothing ;) Using Spy++, I see that the message pane is a seperate window class.
Can't we see if it has focus, and let typeahead steal the `/` accelerator then?
This would mean that two accelerators overlap, but this would only occur when
two things happen:

1.The news component is active
2.The news message window has focus

This gives us the advantage of keeping the known `/` accelerator for the news
component, while keeping the known `/` accelerator everywhere else. The only
disadvantage is accelerator overlap.

All in all, that sounds acceptable to me... personally, I think that when the
message pane has focus, no actions should be taken on any of the other panes,
but I guess that would be another bug entirely ;)



UI -- the `/` and `'` in the edit menu would do nothing? Or would they start
typeahead? Personally, I would have to say no to that. Think of it this way -- 
(*)If they do nothing, they would confuse the user. They would be a dead UI element.

(*)If they start the find, they would _seem_ to do nothing -- remember that
there is no visual confirmation that typeahead starts (no message in the status
bar, no modal, nothing until you actually type). And, as a user, when I click on
a item in a menu, I expect a modal. Or visual confirmation. Something.

So, we should document typeahead well, and make the accelerators work in as many
places as possible. When this happens, we will not need UI elements -- the users
will know that `'` and `/` start a nice find sequence.

Comment 7

[Owen Marshall (Not reading bugmail)]

By the way... I filed bug #184105 about visual confirmation about typeahead
elements. Aaron, if you check in my patch, my gripes about the lack of
confirmation (esp. for a UI element) will be solved, and a UI link could be
created somewhere.

Comment 8

[Aaron Leventhal]

This fix for this is intertwined with my fix for bug 176296. Seth, could you r=
the mailnews changes in that bug?

Comment 9

[sairuh (rarely reading bugmail)]

see bug 187511 to add find as you type to the menus.

Comment 10

[Aaron Leventhal]

checked in

Comment 11

[sairuh (rarely reading bugmail)]

not working in today's builds, so i presume this was backed out as well.
regardless, reopening.

Comment 12

[sairuh (rarely reading bugmail)]

looks like this was fixed when the patch for bug 187511 was checked in.

Comment 13

[sairuh (rarely reading bugmail)]

note: windows to check:

mailnews 3pane
mail standalone
mail compose (shouldn't have the menu items)

Comment 14

[sairuh (rarely reading bugmail)]

semi-blocked verifying this mac, due to bug 195830.

Comment 15

[sairuh (rarely reading bugmail)]

vrfy'd fixed with 2003.03.13 comm trunk, all platforms (other than the mac issue).