Closed Bug 187511 Opened 22 years ago Closed 21 years ago

Add Find As You Type to menus

Categories

(SeaMonkey :: Find In Page, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: aaronlev, Assigned: aaronlev)

References

Details

(Whiteboard: [adt1])

Attachments

(2 files, 5 obsolete files)

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?
Hardware: PC → All
Attached image Screen shot, without separator (obsolete) —
Requesting comments.
see bug 183998 to implement find as you type in mailnews.
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.
Attached patch Looks better with separator line (obsolete) — Splinter Review
Attachment #110636 - Attachment is obsolete: true
Attachment #110808 - Attachment is obsolete: true
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?
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."

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

does this turn on caret browsing mode, or not?
> 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.
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?
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.
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   /
-----------------------
...
> 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!").
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."
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 :)
Well you people sure know how to shoot down an idea. :-)
Attachment #110637 - Attachment is obsolete: true
Attachment #110839 - Flags: superreview?(jaggernaut)
Attachment #110839 - Flags: review?(sgehani)
Comment on attachment 110839 [details] [diff] [review]
Adds menu items in browser, view source, mailnews

changing review from samir to shliang.
Attachment #110839 - Flags: review?(sgehani) → review?(shliang)
r=sspitzer for the change to mailWindowOverlay.xul

I'll leave the rest for shliang / jag (or other reviewers)
I agree, there is no need to add an alert.
Robin or Jatin, can you suggest the correct capitalization of these new items?

Find Links As You Type 
Find Text As You Type
Jenifer, Jatin and I already covered that for the prefs panel. He wants Find
capitalized, but not the rest.
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".
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.)
Correct, the cap style looks OK for menus (Find Links As You Type, e.g.).
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".
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).
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).
Okay, changing to "Find As You Type". I won't submit a new patch for r= unless
asked for one.
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
Attachment #110839 - Flags: superreview?(jaggernaut) → superreview+
Jag, you're right, the newtab/Insert stuff is part of a different bug.
Depends on: 176296
Comment on attachment 110839 [details] [diff] [review]
Adds menu items in browser, view source, mailnews

r=shuehan
Attachment #110839 - Flags: review?(shliang) → review+
checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Bad bad bad.

Bug 189093
Bug 188101

You now cant type apostrophes in text boxes.
I'll have to back this out when the tree opens.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
When this patch is applied, / should work in a textarea, but ' will still get
swallowed.
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 :-/
Attachment #112430 - Attachment is obsolete: true
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.
Sarah, Brade's planning to help me test it.
Attachment #112803 - Flags: review?(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.
Attachment #112803 - Flags: review?(brade) → review+
Attachment #112803 - Flags: superreview?(jaggernaut)
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.
Attachment #112803 - Flags: superreview?(jaggernaut) → superreview?(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.
Attachment #112803 - Flags: superreview?(dveditz) → superreview+
Attachment #112803 - Flags: approval1.3b?
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.
Attachment #112803 - Flags: approval1.3b? → approval1.3b-
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.
Attachment #112803 - Flags: approval1.3b- → approval1.3b?
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.
Attachment #112803 - Flags: approval1.3b? → approval1.3b-
Nav triage team: nsbeta1+/adt1
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt1]
checked in
Status: REOPENED → RESOLVED
Closed: 22 years ago21 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
checking this in caused bug 195830.
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: