187511 - Add Find As You Type to menus

Status: VERIFIED FIXED

(SeaMonkey :: Find In Page, defect)

Description

[Aaron Leventhal]

I propose 2 new menu items under the Edit menu, so that Find As You Type 
generally, and these shortcuts specifically, are both discoverable.

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

* Should they go after the other find options in edit?
* Should there be a separator before they start?
* Should it be included in mailnews, view source, help or other places?

Comment 1

[Aaron Leventhal]

Attachment: Screen shot, without separator

Requesting comments.

Comment 2

[Aaron Leventhal]

Attachment: Adds menu items to browser only. Should we add them to mailnews?

Comment 3

[sairuh (rarely reading bugmail)]

see bug 183998 to implement find as you type in mailnews.

Comment 4

[Aaron Leventhal]

As Gail and Lori suggested, I added the menu separator line. I like the new look.
Also, I added it to the view source menus.
Now I'm just waiting to see what jglick says about adding it to the mailnews menus.

Comment 5

[Aaron Leventhal]

Attachment: Looks better with separator line

Comment 6

[Aaron Leventhal]

Attachment: Looks better with separator line

Comment 7

[jglick]

Does simply selecting these menu items from the Edit menu perform any action? Or
are they simply there to help folks discover the shortcuts for this feature?

Comment 8

[Aaron Leventhal]

If you select the menu item, the caret will start blinking in the content area,
and the status bar says
"Starting -- find text as you type"
or
"Starting -- find links as you type"

At that point, anything the user types will find as they type.
At any point, Find As You Type will timeout if the user does nothing for several
seconds, and the status bar will say "Find As You Type stopped."

Comment 9

[sairuh (rarely reading bugmail)]

> If you select the menu item, the caret will start blinking in the content area

does this turn on caret browsing mode, or not?

Comment 10

[Aaron Leventhal]

> If you select the menu item, the caret will start blinking in the content area
does this turn on caret browsing mode, or not?

No. You'll notice that during find as you type, the selection turns green and
the caret starts blinking. That doesn't relate to caret browsing mode -- we  use
the caret to indicate that something live is happening at that place in the
content while you type -- in this case Find As You Type.

Comment 11

[jglick]

Thanks for the clarification. As for including this in the Edit menu of other 
apps and windows, specifically Mail, I'd appreciate feedback from others. I 
think having this in the Edit menu is a good idea for discoverability reasons 
(esp in the browser where this is very useful), but I am concerned about adding 
more items to the Edit menu for Mail. Do folks feel this feature will be used 
often enough in Mail that the menu items should be included?

Comment 12

[(not reading, please use [e-mail] instead)]

lots of people use ctrl+f (find in message) in mail (3 pane and the stand alone
msg window).

once those people discover type ahead find (especially type ahead find text), my
assumption is they will want to use it in mail.  (the bug that covers getting
this to work in mail is under review.)

if we think it's worth having these edit menu items in browser, I think it's
worth adding them to mail.  might as well be consistent, and keep the edit menus
in sync.

jen's point about "too many items" is fair, and I know the menu specs have been
a point of debate.

let's add these menu items, and if we decide five (top level) find related menu
items is too much for browser and mail, we can deal with it then.

Comment 13

[jglick]

OK, lets add to Mail as well. Thanks for the feedback Seth.

Find in This Msg
Find Again
Find Previous
-------------------
Find links as you type  '
Find text as you type   /
-----------------------
...

Comment 14

[Alex Bishop]

> jen's point about "too many items" is fair, and I know the menu specs have
> been a point of debate.

You see, this is why we shouldn't have got rid of the Search menu. ;-)

Seriously, I think these menu items would be a good idea in MailNews. People
will assume it doesn't work there otherwise.

On a more general note, it might confuse some people that nothing obvious
happens when the user selects one of the Type As You Find (or whatever it's
called now) menu items. Perhaps a brief alert that appears the first time one of
the items is selected would solve this (though if mpt was still here, he would
no doubt scream "No, not another alert!").

Comment 15

[Aaron Leventhal]

I don't know about an alert -- maybe we could draw attention to the status bar
or something. Anyway, that would be a different bug, IMHO. Hopefully, we'll get
some usability studies underway on Find As You Type.

Personally, I'm hoping that people try typing after they select the option,
because of the feature name "Find As You Type."

Comment 16

[sairuh (rarely reading bugmail)]

i'd prefer not see an alert dlg for the initial use of find as you type. i
really think the highlighting and statusbar info are enough. (my own $0.02 :)

Comment 17

[Alex Bishop]

Well you people sure know how to shoot down an idea. :-)

Comment 18

[Aaron Leventhal]

Attachment: Adds menu items in browser, view source, mailnews

Comment 19

[(not reading, please use [e-mail] instead)]

Comment on attachment 110839 [details] [diff] [review]
Adds menu items in browser, view source, mailnews

changing review from samir to shliang.

Comment 20

[(not reading, please use [e-mail] instead)]

r=sspitzer for the change to mailWindowOverlay.xul

I'll leave the rest for shliang / jag (or other reviewers)

Comment 21

[(not reading, please use [e-mail] instead)]

I agree, there is no need to add an alert.

Comment 22

[jglick]

Robin or Jatin, can you suggest the correct capitalization of these new items?

Find Links As You Type 
Find Text As You Type

Comment 23

[Aaron Leventhal]

Jenifer, Jatin and I already covered that for the prefs panel. He wants Find
capitalized, but not the rest.

Comment 24

[jglick]

Aaron, I meant capitalization of the menu items specifically. Capitalization
used in the pref panels is different that capitalization of menu items. In
Prefs, checkboxes/radio buttons normally capitalize only the first letter of the
first word in a phrase. But in the menus we use initial caps format, like "Find
in This Page".

Comment 25

[sairuh (rarely reading bugmail)]

re comment 22: the capitalization for the menu items looks fine to me. iirc from
email with Steve, each word would be capitalized when referring to the feature
or in menus. (cc'ing Steve in case i misremembered.)

Comment 26

[rudman]

Correct, the cap style looks OK for menus (Find Links As You Type, e.g.).

Comment 27

[Aaron Leventhal]

Steve, I'm confused - I think Sarah is saying it looks fine as it is in the
screen shot ("Find as you type"). I think Steve is saying to do it like "Find As
You Type".

Comment 28

[rudman]

I thought Sarah was referring to the text as it appeared in comment #22. All the
words should have initial caps, even "As" (per Chicago Manual of Style title cap
style, the default style for menu items).

Comment 29

[sairuh (rarely reading bugmail)]

nope, i'm referring to the menu suggestions in comment 22, not attachment 110809 [details].

aaronl, i think the "Find as you type" format (as in the screenshot) would be
fine for the pref panel --but that's covered by bug 169489 (well, no recent
screenshot there, but it was discussed over email, iirc).

Comment 30

[Aaron Leventhal]

Okay, changing to "Find As You Type". I won't submit a new patch for r= unless
asked for one.

Comment 31

[jag (Peter Annema)]

Comment on attachment 110839 [details] [diff] [review]
Adds menu items in browser, view source, mailnews

>Index: xpfe/browser/resources/content/navigatorOverlay.xul
>===================================================================
>RCS file: /cvsroot/mozilla/xpfe/browser/resources/content/navigatorOverlay.xul,v
>retrieving revision 1.270
>diff -u -r1.270 navigatorOverlay.xul
>--- xpfe/browser/resources/content/navigatorOverlay.xul	3 Oct 2002 11:04:48 -0000	1.270
>+++ xpfe/browser/resources/content/navigatorOverlay.xul	7 Jan 2003 00:18:31 -0000
>@@ -50,6 +50,8 @@
>     <!-- File Menu -->
>     <key id="key_newNavigator"/>
>     <key id="key_newNavigatorTab" key="&tabCmd.commandkey;" modifiers="accel" command="cmd_newNavigatorTab"/>
>+    <key id="key_newTabWithTarget" keycode="VK_INSERT" modifiers="" command="cmd_newTabWithTarget"/>
>+    <key id="key_newTabWithTarget" keycode="VK_INSERT" modifiers="shift" command="cmd_newTabWithTarget"/>
>     <key id="key_newBlankPage"/>
>     <key id="focusURLBar"      key="&openCmd.commandkey;" oncommand="ShowAndSelectContentsOfURLBar();"
>          modifiers="accel"/>
>@@ -109,6 +113,7 @@
>   <commandset id="commands">
>     <command id="cmd_newNavigator"/>
>     <command id="cmd_newNavigatorTab" oncommand="BrowserOpenTab();"/>
>+    <command id="cmd_newTabWithTarget" oncommand="contentAreaClick(event);"/>
> 
>     <command id="cmd_newEditor"/>
>     <!-- NOT IMPLEMENTED

I'm sure you didn't mean these two sections to be part of this patch.

Thanks for catching that key_findPrev thing.

sr=jag

Comment 32

[Aaron Leventhal]

Jag, you're right, the newtab/Insert stuff is part of a different bug.

Comment 33

[shliang]

Comment on attachment 110839 [details] [diff] [review]
Adds menu items in browser, view source, mailnews

r=shuehan

Comment 34

[Aaron Leventhal]

checked in

Comment 35

[Joseph Delaney]

Bad bad bad.

Bug 189093
Bug 188101

You now cant type apostrophes in text boxes.

Comment 36

[Aaron Leventhal]

I'll have to back this out when the tree opens.

Comment 37

[Aaron Leventhal]

Attachment: Test to see if disabled="true" on menu item makes a difference

When this patch is applied, / should work in a textarea, but ' will still get
swallowed.

Comment 38

[Kathleen :Brade]

Comment on attachment 112430 [details] [diff] [review]
Test to see if disabled="true" on menu item makes a difference

This patch causes the ' to not be typeable in a textarea after the Edit menu
has been appeared.  It also disables the entire for Find Text As You Type /

probably not what aaronl was hoping for :-/

Comment 39

[Aaron Leventhal]

Attachment: Makes sure menu items are disabled in editable text fields, lists and in midas

Comment 40

[sairuh (rarely reading bugmail)]

before this is checked in could someone pls test the patch on mac os x, to make
sure bug 189093 doesn't occur. that, or if someone could spin up an opt build
then i'd be happy to give it a whirl.

Comment 41

[Aaron Leventhal]

Sarah, Brade's planning to help me test it.

Comment 42

[Kathleen :Brade]

Comment on attachment 112803 [details] [diff] [review]
Makes sure menu items are disabled in editable text fields, lists and in midas

r=brade

On OSX, I tested midas, text fields and textareas as well as the feature and
all seem to work fine.

Comment 43

[Aaron Leventhal]

Comment on attachment 112803 [details] [diff] [review]
Makes sure menu items are disabled in editable text fields, lists and in midas

Since Jag is not around, and I need this for usability tests tomorrow, Samir
has suggested I ask for sr=dveditz.

Comment 44

[Daniel Veditz [:dveditz]]

Comment on attachment 112803 [details] [diff] [review]
Makes sure menu items are disabled in editable text fields, lists and in midas

sr=dveditz

>+// update Find As You Type menu items, they rely on focus
>+function goUpdateFindTypeMenuItems()
>+{
>+  goUpdateCommand('cmd_findTypeText');
>+  goUpdateCommand('cmd_findTypeLinks');
>+}

I have a minor worry about the perf impact here, keep an eye on it after you
land.

Comment 45

[Asa Dotzler [:asa]]

Comment on attachment 112803 [details] [diff] [review]
Makes sure menu items are disabled in editable text fields, lists and in midas

This looks large and featurish and I think should wait until we open for
1.4alpha.

Comment 46

[Aaron Leventhal]

Comment on attachment 112803 [details] [diff] [review]
Makes sure menu items are disabled in editable text fields, lists and in midas

Asa, it's not really new. This had been checked in before, but was temporarily
backed out because of a regression on Mac OS X. We need this to be in the bits
being pulled for usability testing tomorrow.

Comment 47

[Aaron Leventhal]

Comment on attachment 112803 [details] [diff] [review]
Makes sure menu items are disabled in editable text fields, lists and in midas

Well, I gave in to the decision. I'll make a special build for the usability
testers.

Comment 48

[Samir Gehani]

Nav triage team: nsbeta1+/adt1

Comment 49

[Aaron Leventhal]

checked in

Comment 50

[sairuh (rarely reading bugmail)]

menu items work fine in browser. they don't appear in composer, addrbk or im
windows. menu access keys work fine on win2k and linux rh8.0. (mailnews stuff
covered by bug 183998.)

vrfy'd fixed with 2003.03.03 comm trunk bits.

new issues pertaining to this change should be spun off as separate bugs.

Comment 51

[sairuh (rarely reading bugmail)]

checking this in caused bug 195830.