Closed Bug 30088 (isearch) Opened 25 years ago Closed 22 years ago

Incremental find (like Emacs isearch) (type ahead find)

Categories

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

Product:
SeaMonkey
Component:
Find In Page
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: maratb, Assigned: aaronlev)

References

(Depends on 3 open bugs, Blocks 1 open bug,
URL
)

Details

(Keywords: access, helpwanted, meta)

Attachments

(6 files, 8 obsolete files)

content search toolbar mockup
15.82 KB, image/png
Details
xpfe/components/find/resources/finddialog.js code w/ isearch functionality
6.07 KB, text/plain
Details
embedding/components/find/public/nsIWebBrowserFind.idl w/ the iSearch attribute added
5.99 KB, text/plain
Details
embedding/components/find/src/nsWebBrowserFind.cpp w/ isearch code
29.17 KB, text/plain
Details
the .h file
4.68 KB, text/plain
Details
Correct configure.in and allmakefiles.sh changes
1.83 KB, patch
netscape
: review+
jst
: superreview+
Details | Diff | Splinter Review 
Incremental text searches in Mozilla would be (IMHO) a great usability
enhancement for advanced users.  What I have in mind, is Emacs-like "isearch"
functionality that searches through a page as the user types in the search text
character by character.
Assignee: cbegle → don
Component: Browser-General → XPApps
QA Contact: asadotzler → paulmac
Summary: Incrementally search text on a web page → [RFE] Incrementally search text on a web page
Find on Page -> XP Apps
Status: UNCONFIRMED → NEW
Ever confirmed: true
spam: moving qa contact on some bugs from paulmac to sairuh@netscape.com
QA Contact: paulmac → sairuh
Target Milestone: --- → Future
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → vishy
nav triage team:

I *LOVE* isearch under emacs, unfortunately, don't think we'll get to this. 
Marking nsbeta1-
Keywords: nsbeta1-
Someone authorized should add "Emacs" to the summary of this bug to make it
easier for people to find it.  Bug 84708 is a duplicate of this one that was
filed at a much later date but has more votes anyway.  My guess is that's
because people can't find this one (because they look for "Emacs", not
"incremental").

Changing summary, as per Johan Walles' comment.
Summary: [RFE] Incrementally search text on a web page → [RFE] Incrementally search text on a web page (like Emacs isearch)
*** Bug 84708 has been marked as a duplicate of this bug. ***
This could be done on top of the existing Find API, but Find would have to be 
faster (bugs exist).

Great idea.  I want to help.  (I'm a programmer, and
a Mozilla user, but haven't [yet] done any Mozilla programming.)

Here's some thoughts:

- For UI, I think it would be relatively simple to add a
"Search interactively" (somebody come up with a better
term -- "Match after every keypress"?) checkbox to the
dialog.  I'm not sure this is the ideal long-term solution,
but it would allow adding this feature without breaking
the existing Find.
- Composer and Mailnews have a slightly different dialog,
because they do find/replace.  This might not be the best
way to go about it.
- For implementation, maybe steal some of autocomplete's
code, because they also search-at-every-keypress.

Comments?  Is anybody interested, and have time for this?
Actually, I have given some thought to the UI of this beast.  I think that, at
least for starters, the Find UI can be left exactly as it looks today.  Why have
a checkbox for the user to choose between the (nice) Emacs-like search and the
current (harder-to-use) one?

Anyway, I haven't ever looked at a single line of Mozilla code, so this advice
may or may be any good, but it should be possible to do whatever the "find"
button does every time the user presses a key.  When the "find" button is
pressed, go look for the next instance.

In the longer term, the "wrap search" checkbox could probably be removed.  When
the search term is not found, the text of the "find" button could be changed
into "find from beginning" or "wrapped find" or something.
Regarding the find/replace issue, I think the find part of find/replace should
probably act like Emacs isearch as well.  The replace part could go untouched.

I'm sorry I don't have the time to help with the implementation (I have thought
about doing it myself but like many others never gotten around to it).  I can
however do the back-seat driver part of the development :-).

Have fun!  I'm anxiously looking forward to any results :-).  Cheers //Johan
trudelle to triage
Assignee: vishy → trudelle
oh, perhaps this should go to akkana?
Assignee: trudelle → akkana
mass moving open bugs pertaining to find in page/frame to pmac@netscape.com as
qa contact.

to find all bugspam pertaining to this, set your search string to
"AppleSpongeCakeWithCaramelFrosting".
QA Contact: sairuh → pmac
I think this should be wontfix.  I'm not aware of any indication that typical
users have a need for this, I suspect it would be too geeky for them anyway, and
would conflict with scrolling via spacebar.  Can anyone point out any
widely-used  product that has this? (no, Emacs doesn't even come close)
See
http://www.jefraskin.com/forjef2/jefweb-compiled/unpublished/widgets_of_the_week.html#anchor1104954
for an explanation of why one UI expert thinks incremental search is best.

You can't have it both ways. If there aren't widely-used products with this
feature, people aren't going to request it explicitly. They're just going to
notice that the current 'find in this page' is clunky to use.

There's no reason at all for it to conflict with scrolling using the spacebar.

Note that incremental search has already been implemented in Mozilla, in the
mailnews folder pane (Viev|Show/Hide|Search Bar). A similar search toolbar for
(browser) content would be consistent and I wouldn't imagine it would be any
more confusing for a beginner user than a search dialog. Here's what it might
look like:
- a label "Search for:"
- text entry field
- a "Find Next Occurrence" button (ctrl+g should do that too as it currently does)
- "Options" button to enter dialog to configure case sensitivity etc... Or maybe
rather a popdown menu with checkmarkable items, like the tree columns control,
that would do away with a silly dlg...
- X to close the toolbar (maybe)

And no, it doesn't conflict with scrolling with the spacebar any more than the
current search dialog.
s/mailnews folder pane/mailnews thread pane/
Okay thanks. I misunderstood the intent, and thought this was more of a
type-select as in some list interfaces.  This is a pretty interesting idea, it
just needs some design, and probably some performance tweaks as sfraser hints. 
I've talked recently with the mail guys about extending use of their incremental
search, but unfortuanately the current implementation is pretty tied to the
lists where it is used.  We should certainly look into adding this in the next
release.  cc'ing scc for thoughts on adapting some of his search algorithms to
this, and marlon for UE input.
I'm assuming adding a search toolbar (as shown in the attachment) isn't covered
by this bug, and is filed as a separate bug if anyone is requesting it.

The backend for incremental search probably wouldn't be too hard.  And a front
end could be tested fairly easy -- add a toggle button for incremental mode on
the regular search window.  I'll experiment with this sometime if I get some
time (and after the open bugs on regular searches are fixed, so don't expect
anything before moz 1.0).
Status: NEW → ASSIGNED
First off let me preface this comment by saying that I downloaded the source
yesterday for the sole intent of adding this feature for my personal use, I
think it is that important.

This feature is not found in many products, I do know that in addition to emacs,
MSDevStudio has (or at laeat had) this feature, but you needed to explicity map
a key to it for it to work).  This is one of the reasons you almost never hear
good emacs people complain about huge source files,  they _never_ use a
scrollbar (it is just too slow)

Most people will love this feature if it can be put in.  It massivly improves
the speed at which someone can find text in a document.  Not only do you not
have to type more letters than are absolutely needed to find the substring, you
_never_ have to take your hands off the keyboard!  (Now that's fast).  Imagine
being able to follow a link by just typing the first couple of letters in the
link and hitting enter.  For us fast typers out there, this would be really cool.

That said, the feature should probably not bring up a dialog box as that might
introduce focus issues, as well as obscuring the text that you are searching for.

I would love to implement this feature, but I need to learn the product much
better first.  Can someone point me twards some info on how keyboard events are
handled in mozilla?


I, too, might help out, if I had any clue of how to go about doing it.
I did make a search toolbar front-end once, but that's about as far as I got.
Geoffrey: if you want to work together to figure out how to do this (as
two Mozilla rookies), I'd be happy to work with you.  Maybe I still have
it lying around somewhere...
Sorry for the delay; partly it's because I don't know where this should go
either ...

You could probably handle key events in JS -- look at how the mouse events are
handled (e.g. in contentAreaClick.js), and I imagine that keyboard events could
also be handled in a similar way.  If you can handle it this way rather than in
C++, you'd probably be better off as long as the performance was okay, so I'd
recommend looking into this first.

In C++, keyboard shortcuts are handled via two mechanisms: XBL and XUL.  See
http://www.mozilla.org/unix/customizing.html for a little information about the
difference.  XBL key events are mostly handled in nsXBLKeyHandler.cpp and other
files in the same directory (content/xbl/src).  I'm not sure where XUL key
events are handled -- probably layout/xul/base/src/nsMenuListener.cpp or
somewhere like that.

In practice XBL key events are easier to debug and faster (IME), but XUL might
be more appropriate for this sort of functionality since that way it could be
easily added as a .xpi for people who want it.

The low-level key events are handled by platform specific files, e.g.
widget/src/gtk/nsGtkEventHandler.cpp.  You shouldn't need to add anything in
these files; I mention them only in case you want to look and see how they're
implemented at the lowest mozilla level.

The find code is in embedding/components/src/nsFind.cpp.  That implements the
nsIFind interfaces, which is exposed to JS; you might also be able to use the
slightly higher level nsIWebBrowserFind interface. 
editor/ui/dialogs/content/EdReplace.js is an good example of how to use both of
these interfaces from JS.
Aaron tells me that Jesse has a partial implementation of incremental search. 
If it's close to working, maybe we can work together and get it checked in ...
Added a key handler to implement incremental search
Simply sets the region to search from the beginning of the selection if in
isearch mode.
Attached file the .h file — 
Just the .h
I have a partial solution that works for me.  It modifies the current find
dialog box to do incremental search.  It is far from perfect, and it ruins the
current find functionality.  Nevertheless, it is a good starting point for
someone who wants to "featureize" it, and for those who are dying for
incremental search (like me), it might satisfy thier needs.  I'll attempt to
attach the changed files.

The way I have it working is:  When you bring up the find dialog, after every
key typed, the selection moves to the earliest match after the _beginning_ of
the current selection.  Hitting Ctrl-S searches to the next match, Ctrl-R goes
backwards. Enter closes the dialog box, so that hitting enter twice will follow
the selected link.

Note:  I still think the proper way to do this is W/O any dialog.  I like the
proposed search toobar idea, however manually changing focus to/from the toolbar
kinda defeats the purpose.

The changes I made are as follows:

embedding/components/find/public/nsIWebBrowserFind.idl:
  Added the attribute iSearch, this attribute is set to "on" by the find dialog.
when iSearch is true, find next does not advance to the next selection if the
current search string still matches the word(s) at point.

embedding/components/find/src/nsWebBrowserFind.cpp:
embedding/components/find/src/nsWebBrowserFind.h:
  Added small bit of code to handle the iSearch attribute, as well as modifying
the code to set the range of text subject to searching.

xpfe/components/find/resources/finddialog.js:
Added an onkeypress event handler to do the right thing as the user types in the
search string.
Blocks: 154414
You can't change nsIWebBrowserFind.idl. It's a frozen, public embedding
interface. You'll have to make a new interface for incremental find.
Jesse Ruderman's bookmark demo version does not need to change any interfaces.
It also works without a dialog box, as you start typing. He says he will upload
this later today.
I don't have a copy of the bookmarklet at home.  I'll upload it the next time
I'm at work.
Summary: [RFE] Incrementally search text on a web page (like Emacs isearch) → [RFE] Incremental find (like Emacs isearch)
Bookmarklet demo of an incremental find feature:
http://www.cs.hmc.edu/~jruderma/mozilla/incfind/
I have a fix that works pretty well for this.
Assignee: akkana → aaronl
Status: ASSIGNED → NEW
This patch accomplishes typeahead find by listening to keypress events on the
current window. I've hacked on it quite a bit, it has a lot of nice features
already.

It would be nice to get this in soon, so that more people can play with it and
hack on it. We can make it part of the build later, once it's smoothed out.

Seeking r=.  Akkana?
Makefile.in instead of makefile.in, change REQUIRES to point to the right
things, stricmp doesn't exist on Linux, reorder some initializerrs to prevent
build warnings. This should be applied on top of Aaron's patch.
If this is not part of the build then you can check in w/o a review, once it's
turned on in the build you need to get the code reviewed...

        Attachment #90473 -
        Attachment is obsolete: true

        Attachment #90475 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 90515 [details] [diff] [review]
Includes bz's changes, and removes nsEventStateManager changes (which I put in bug 156301 now)

>Index: mozilla/extensions/typeaheadfind/makefile.in
>===================================================================
>RCS file: mozilla/extensions/typeaheadfind/makefile.in
>diff -N mozilla/extensions/typeaheadfind/makefile.in

No, unix is case sensitive.  The file name should be "Makefile.in" (note the
capital M)

    
    

    
  
Aaron, you lost the Makefile.in changes (in particular the REQUIRES changes
needed to build this on Linux) and the 

-XPIDLSRCS= .\nsITypeAheadFind.idl \
+XPIDLSRCS= ./nsITypeAheadFind.idl \

change...

Since I have this built and all, is there a way to actually trigger it?  I don't
know much about the Find stuff, so I'm not sure how to actually hook this up so
I can try it...

    
    

    
  
Bz, thanks, I have those changes now

These prefs will make it work:
user_pref("accessibility.typeaheadfind", true);
user_pref("accessibility.typeaheadfind.linksonly", true);
user_pref("accessibility.typeaheadfind.timeout", 3000);

The timeout pref is the number of milliseconds before the current type ahead
find is cancelled. At that point, space bar will scroll again, and typing more
characters will start a new find.

I recommend people try both settings for the linksonly pref, but I have found in
real use that I pref linksonly = true.  Typing a quote before your find will
cause it do to the opposite of that pref. For example, it will now incrementally
 search all text instead of just links. I realize this isn't discoverable, but
it's a nice extra that we could document.

    
    

    
  
I just checked this into extensions/typeaheadfind (not as part of build).

There's a bug where there is some occasional ghosting of focus outlines. The
1-line fix for that is in bug 156301. I'm seeking sr= for that patch.


Status: NEW → ASSIGNED

    
    

    
  
Could someone get this building on mac and check in code warrior project files?
It should not yet be part of the default build.
Depends on: 156301
Keywords: access
QA Contact: pmac → sairuh

    
    

    
  
Akkana has this running under Linux, but you have to tab or click into the
document first, unfortunately. We'll need to fix that.

Still no volunteers to get this running on a Mac?

    
    

    
  
question: when i last discussed this with aaronl, i thought that this feature
would become an installable xpi --is that still part of the plan? this would be
esp useful for testing and using with verification builds.

    
    

    
  
Here are XPI's for testing it on Linux and Windows:
http://www.mozilla.org/projects/ui/accessibility/typeaheadfind.html

There's even an XPI there for loading it onto Netscape 7 or Mozilla 1.0.

    
    

    
  
New changed based on feedback from emacs users:
When you type repeated characters, it now prefers to find an exact match. For
example, on the mozilla.org home page, "ll" will get you to "Mozilla". Typing
more l's will start to cycle through the links that start with l, because there
is no exact match. I think this is a better compromise than what we had, where
it always started to cycle through the links on repeated characters.

I updated the Windows XPI's at:
http://www.mozilla.org/projects/ui/accessibility/typeaheadfind.html

Another tweak is that the selection no longer collapses on the timed cancel when
you do a search on all of the text. (You can search all text instead of just
links by typing ' first). It was dissorienting when that happened.

    
    

    
  
I'm using the XPI right now (thanks Aaron!). The following comments are biased
by my experience with Emacs and MS Visual Studio (the only programs I know that
have isearch...)

First impressions:
- From the web page I got the impression that there should be feedback through
the status bar, but this isn't happening.
- What is the motivation for the timeout? I found it rather incovenient and
distracting, and since just about any other action cancels the find, it seems
unnecessary.
- Typed characters that don't match are ignored. This is different from the
other apps and so a little disorienting. I'm used to typing Backspace when I
enter a character that doesn't match, but here that deletes the last character
that did match. This isn't necessarily wrong, just different from what I was
expecting.

On UI feedback:
I really think that putting up a dialog box would be Wrong. What makes isearch
so great ist that it's so streamlined. You end up using it all the time.  Having
windows pop up is distracting and gets in the way of the search (litteraly).
Both emacs and VS simply display the string being searched in the status bar.


    
    

    
  
_WOW!_ I love this feature, this is way better that that original hack I put up
here.

Some usablility comments:

1) I agree with that last comment in respect to how backspace should work, and I
would also love to see some feedback in the status bar.  

2) Sometimes I have the need to search the entire text of a page, not just the
links.  Perhaps this mode could be entered by typing a key while searching. 
Take this scenario (I assume that we are using the status bar):

   - I start typing in "mo" and it immediatly starts to move to a link
containing the word "mozilla", good.   As I'm typing the status bar says
something like 
"Searching links for: \"mo\"".  Now, say, I'm really looking for the word
"modern" but _not_ in a link. I type the letter "d", and the status bar updates
to something like "Failed searching links for: \"mod\"".  At this point (or
actually any other point too), I'd like to be able to hit a magic key
combination that would change the search context from links to the whole
document... So..  I hit Ctrl-Alt-S (I can't think of a better key combo that
isn't taken), the status bar updates to  "Searching document for: \"mod\"" and
selection jumps to the first work starting with "mod".

3) A cool to have feature, that emacs has is the ability to reverse a search. 
So  , say I search for "Modern" and I find one, then skip to the next one and
then the next one, and I get carried away and go right past the one I wanted...
 In emacs, you can hit Ctrl-R, and it will reverse the direction of the search
from the current point, So now, I'm searching backwards for the same word.

4) Another cool to have feature implemented by emacs is "Yank word from buffer
onto end of search string and search for it"....  The best way to experience
this one is to try it in emacs.  I'll attempt to explain.  Say I'm searching for
"mo" again...  The first hit I get is "modern", the word that I'm searching for,
but not the right instance of the word.  In emacs, if I hit Ctrl-W at this
point, emacs will take the whole word "modern" and search for it without me
having to type in the whole word.  This is really usefull when searching for
long words.



Once again, I love this feature.

    -Geoff

    
    

    
  
re comment 49, item 2.  See comment 47, last paragraph, parenthetical aside.

    
    

    
  
offhand borland dev apps had isearch.
Alias: isearch

    
    

    
  
ok, this ROCKS!  thank you thank you thank you!  except that i'm seeing a large
number of big bugs:

* moz crashed when i tried to quit after installing this XPI (talkback ID
TB8258875X)
* can't forward emails, it comes up with all fields blank
* the browsers launches with blank window, not the homepage as it should
* right clicking a link in a mail and choosing "open in new window" pops up a
blank window

should i post these as i find them to this bug?

    
    

    
  
is there a way to uninstall this?  its a very good idea, but has hosed my
browser pretty badly, i'd rather not blow away my profile if possible.  thanks.

    
    

    
  
Josh, those sound like problems we had with a nightly a few days back (unrelated
to this patch/XPI)...  What exact build did you install the XPI on?

    
    

    
  
using 2002070908 ... i'll go ahead and grab a newer nightly, though i didnt see
these problems til i ran this XPI ... 

    
    

    
  
ok, new build, all is good again, sorry for the spam folks :)

    
    

    
  
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=jst%25netscape.com&whotype=match&sortby=Change+Size&hours=2&date=explicit&mindate=2002-07-09&maxdate=2002-07-10&cvsroot=%2Fcvsroot
the first checkin in the list.  That fixed the problems you are seeing (which
_were_ exacerbated by typeaheadfind).  Your build is from the exact day when
lots of stuff was broken, with or without typeaheadfind.

    
    

    
  
Thanks for all the comments!

To uninstall, just search for typeaheadfind.* in your build and delete all those
files.



    
    

    
  
how do i enable this in my personal build? (One I compile myself, i.e. not using
the XPI.)

Based on comments, I agree that the status bar should give feedback:

   Incremental Search: Mozil                      (user has typed "Mozil")
   Incremental Search: Mozill                     (user typed "l")
   Incremental Search: Mozilll [no match]         (user typed a third "l")
   Incremental Search: Mozill                     (user pressed backspace)

    
    

    
  
> To uninstall, just search for typeaheadfind.* in your build and delete

Actually *typeaheadfind* (deleting the library, which on linux is called
libtypeaheadfind.so, is the most important part of uninstalling).

> how do i enable this in my personal build? (One I compile myself

From the top level:
cvs co extensions/typeaheadfind
cd extensions/typeaheadfind
make (or equivalent if not using gmake)

That's all that should be needed.

The linux xpi was updated this morning after Aaron's changes from comment 47.

    
    

    
  
This is a cool feature, but why is it configured to search only URLs by default?
 Aren't most people usually searching for *any* occurrence of the search string?
I search a lot, but I don't think I have ever wanted to restrict a search to
only URL text.  Am I wierd? (in that way ;-) It seems like restricting the
search in such a way should be an exception case, requiring extra effort to
invoke (if it really needs to be supported at all), not the norm. 

    
    

    
  
This is just for ease of navigation when not wanting to use the mouse, at least
that's what I thought. I find that more useful than having this find any kind of
text, I don't use it as a shortcut to Find, I use it to quickly focus a link and
load it... But who knows, maybe I'm the one who's weird here :-)

    
    

    
  
Well, the original report was for incremental text search 'through a page', no
mention of links or navigation.

    
    

    
  
I'm with Peter -- I want it to find through normal text as well as links, and I
also want it to stop forgetting its selection position (i.e. no timeout) so I
can pause for a few seconds and still be able to continue the search.

But obviously there are opinions on both sides, so we'll need to figure out what
the majority of users would prefer.

Mouseless/disabled users will probably prefer the current setting (links only)
but they're no more "average users" than we are, and probably just as used to
fiddling with prefs rather than accepting the defaults.

    
    

    
  
Even if you're in the "search only links" camp, it seems to me that the only
time that the "search all text" behavior is inconvenient is when the text you're
searching for as a link is also in the document as a non-link.   This doesn't
seem like the common case; for example, on this bugzilla page it seems that most
links would be found equally quickly even if you were searching all text.

Additionally, it matches my mental model to make "search only links" be the
action that requires the modifier key; after all, if I'm going to search for
modified text, it makes sense I need to indicate that somehow.  The way things
are now, when I want to search for normal text, it requires me to hit a special key.

Then again, maybe it's the fact that over the past decade the emacs-like
behavior has become hardwired into my brain, so I'm clearly going to be in the
"search all text" camp.  (And that's why I found the bug in the first place)



    
    

    
  
Minor but irritating bug with the current code: if focus is in an <input
type=file>, any character typed will go to the input but will also go to the
page.  For instance, click on "Create a new attachment" and type some characters
into the filename field -- you get lots of failed-search beeps while you type.

Move focus to the next text field (Description) and you can type normally, no beeps.

Perhaps input type=file doesn't do a preventBubble when it should?

    
    

    
  
a cool feature! I like it. There are my comments:

1) why did the following two settings miss every time I quit mozilla?
user_pref("accessibility.typeaheadfind", true);
user_pref("accessibility.typeaheadfind.linksonly", true);

2) when linksonly=true, typing letters doesn't find normal text, but Ctrl+G 
does.

3) I also prefer make the finding through *all* text as the default setting, or 
we can use a shortcut key to toggle this setting.

4) I prefer the "find previous" or "find backward" function too :)

    
    

    
  
Note: I think the prefs should be called "extensions.typeaheadfind.*" not
"accessibility.typeaheadfind.*".

I've been having some problems getting this to work, but i need to spend more
time looking at it before complaining...

    
    

    
  
I'd just forgotten to wipe component.reg, my bad.

So yeah, my comments would be: make full search the default, not link search,
and give us some status bar feedback as per comment 59. Otherwise, looks good.

    
    

    
  
This is great, I created the different prefs in hopes of getting a discussion
going about the feature.

I'm really interested to know how many non-Emacs users want text only as the
default. Most of our users are not Emacs users. IMHO, those that are are Emacs
users technically savvy enough to change their pref. I think end-user testing
would show that most people prefer linksonly=true, because in practice I often
end up on text when I'm trying to go to a link. If I'm proven wrong, I'll gladly
change it, but not on the basis of Emacs users who want their old feature - this
is a different application.

I also don't want to get into a legalistic  argument about whether implementing
a superset of the original RFE is appropriate here. Text only search is
available by pressing ' before the text, so the RFE is implemented.

About the status line, it think that the status messages don't show up when
running this in branch-based builds, but they do in trunk-based builds. A lot of
things won't be doable via just the XPI, because they'll require patches to core
code. I'm also not happy with the status messages yet, because they should still
show the target URL of a link that's landed on (in parenthesis?). That's a
little bit harder than it sounds, because it's done via OnOverLink in
nsWebShell.cpp
(http://lxr.mozilla.org/seamonkey/source/docshell/base/nsWebShell.cpp#630). 

If there is going to be a find previous, perhaps it should be via Accel+Shift+G.
I think the same keystroke should mean find backwards for normal find.

Collapsing the selection on timeout has turned out to be a bad idea. It would
also be nice to show that the selection is special somehow. Perhaps there should
be a box drawn around the selection, which disappears when type ahead find mode
ends. The selection text itself would still be highlighted.

In response to some other comments:
> - What is the motivation for the timeout? I found it rather incovenient and
> distracting, and since just about any other action cancels the find, it seems
> unnecessary.
I'm not sure about this, what do other people think? Is the 2.5 second default
timeout just too short? If you set your timeout pref to 0 it gets rid of the
timeout completely.

- Typed characters that don't match are ignored. This is different from the
other apps and so a little disorienting. I'm used to typing Backspace when I
enter a character that doesn't match, but here that deletes the last character
that did match. This isn't necessarily wrong, just different from what I was
expecting.
I don't mind changing this, it's a pretty minor detail in my view. I can see the
point.

> (From Kyle) 1) why did the following two settings miss every time I quit mozilla?
Kyle, I don't understand the question.


    
    

    
  
I take it this still doesn't work on Mac...?  I'm sure I'm not the only person
here with a Mac who'd love to play with this but can't figure out how to build
Mozilla on a Mac.  Surely somebody at Netscape has a Mozilla build configured
on Mac, that this would be a simple matter to compile with...

    
    

    
  
I never used EMACS. Still I think this feature rocks :-)
But IMO a whole text search without a quotation mark before should be either
standard or at least an option. I find it a bit disorienting to type " before I
enter more letters because I've never seen a program that works this way. I
think creating a pref for it would be the best solution.

And concerning the timeout: I also lack to see the motivation it it. But since
you can switch it off I think there's no problem. It's a feature that doesn't
hurt anyone but those who want it can activate it.

    
    

    
  
I've used emacs before but never the incremental search, I'll have to try it. I
never search for links in a page but very often for words or text snippets, so I
vote for searching the whole text as default and links as an option.

    
    

    
  
Out of curiosity, for the people who prefer, "Search in links only," do you
also think the regular old "Find in this page" dialog should have a "links only"
option?



    
    

    
  
On my build (not XPI-based) I get no status bar feedback at all (Mandrake 8.1).

On http://www.internet-masters.com/ao/nanos/ac.html if I search for "wrangle" I
find that the page doesn't scroll down to the incrementally searched match. It
does on Google, though.

    
    

    
  
I think it only scrolls if it finds text in a link.  If you're using
typeaheadfind as a navigation feature (with linksonly), you won't notice the
bug, but if you're using it as a quick way to search, you will.

    
    

    
  
background:
    I'm used to this feature from my text editor and MUA where it
    searches all text. Understandably, I'm hopefull the default
    will be to search all text. This is also how I generally wish
    I could use the normal "find in page" search. Generally, this
    feature is useful to me when I've landed on a page from some
    search engine query, and I need to find the relevant text in
    what may be a large page.

So, my vote is for defaulting to search all text.

I understand how link-navigation can be a handy feature too, and
while I probably wouldn't use it, I would be glad to know it is
there for those users who need/want an efficient keyboard means
for navigating links. Hmmm... Actually, if I could do the
"just prefix your typeing with this special character" thing to
search for links, then I'd probably give it a shot and maybe even
grow to like it.

Suggestion/request... can this be implmented in such a way as to
be universally available? Ideally, you could use the same code in
mail/news and composer as well.

-matt


    
    

    
  
Yes, it is only scrolling for links.

I've found another big bug. The incremental search thing should be disabled in
the message pane of mail and news, otherwise the "n", "b", etc shortcuts don't
work anymore.

    
    

    
  
I'm really surprised that so many people in this bug prefer it as text search. I
wonder if that's a techie thing, and whether most users will feel that way.

The really nice thing about the link search is that the link is automatically
focused for you. So you just type the first few letters of a link, press Enter
and you're there. For me, this is much speedier than using the mouse to navigate
to links, which is what I'm doing most of the time, rather than finding text.
Accel+F is still available for that.

Maybe I should have done the work under bug 105565 instead :(

> Suggestion/request... can this be implmented in such a way as to
> be universally available? Ideally, you could use the same code in
> mail/news and composer as well.

It should work, it is implemented so that any content area should benefit from
it, including embedded browsers using Gecko.

However, as Hixie says, we may have to disable this in the mailnews content
pane, which is too bad.




    
    

    
  
Strange, I would see the search for links as beeing more targeted towards
techies than the whole text search. Keyboard-only browsing seems to me a more
techie-thing because it's not easy to discover how to navigate without the help
of context-menues and the like. But why are you so disappointed? Your great work
should be easily either configurable via preferences or even be accesible via
two different ways to have both features available. And I promise you to look
closer at your idea of "keyboard only" surfing (I've just figured out, how to
open a link in a new windows/tab via Ctrl+Alt+Return, that's a must for
keyboard-browsing).

    
    

    
  
> may have to disable this in the mailnews content pane

Frankly, I'd prefer that it was disabled by default everywhere.

Ideally, I'd like to
    hit a keycommand to start isearch
    type text
    hit enter to find next occurances
    type escape or click anywhere to get out of isearch

but I'll be happy for any sort of isearch :)


> Keyboard-only browsing seems to me a more techie-thing


I'd agree with you there. However, I'm accustomed to using a
mouse, so I don't (yet) miss keyboard navigation of links.

I'm *also* accustomed to isearch-like functionality from my
text editor and MUA, so I very much miss full text isearch
in Mozilla (and many other apps). I'm often using google's
cached pages as a weak substitute because it will help me
find where on the page the hits landed with its hilighting
feature. When I'm not using google, I'm using the normal
"find in page" feature which I wish worked in an isearch
fashion.

-matt


    
    

    
  
I think the problem here is that we are using one interface for two unrelated
features:
a) quick keyboard navigation of links
b) incremental find* 

Making it a pref circunvents the problem, but we could do better. Since they are
really different features why not give them different interfaces?

How about this:
- Link navigation remains as is. Since the search mode is entered implicitly by
typing this won't work in mail or composer, as noted in previous comments. For
this feature I don't think this is a problem, and the convenience is worth it.
- Incremental find is entered explicitly by pressing Ctrl+something. This is how
it works in all those other apps, so it's expected behaviour anyway. As a bonus
this can be made to work anywhere, including Main/News and Composer.


* "incremental find" seems better than "incremental search" since the existing
feature already uses the word "find".


    
    

    
  
How would this functionality work in the presence of accelerator keys in a
webpage?  (ie: accesskey attribute)

    
    

    
  
Ok, so I just ran into a major problem with this, on linux (maybe on Win2k too,
can't tell right now) this code ends up doing it's find thing even when you're
typing in text inputs (i.e. form controls). This sucks, and obviously needs some
fixin'...

    
    

    
  
JST: Are you sure it was in a text input, not a filename input (which looks very
similar)?  See comment 66.  I haven't seen it in real text inputs, though.

    
    

    
  
Oh, yes it was, but that's more than a minor problem, that's a serious problem...

    
    

    
  
Comment on attachment 90515 [details] [diff] [review]
Includes bz's changes, and removes nsEventStateManager changes (which I put in bug 156301 now)

We need the <input type=file> problem solved before we can take this...

        Attachment #90515 -
        Flags: needs-work+

    
    

    
  
> Incremental find is entered explicitly by pressing Ctrl+something. This is how
> it works in all those other apps, so it's expected behaviour anyway. As a bonus
> this can be made to work anywhere, including Main/News and Composer.

Sure, no problem. Accel+J is free, ("Jump to text"?).
Or, we can continue to use one of the printable characters as we do now, such as '

    
    

    
  
> Sure, no problem. Accel+J is free, ("Jump to text"?).
> Or, we can continue to use one of the printable characters as we do now, such as '

A proper Accel shortcut is needed to make it usable outside the browser (e.g.
composer).
That's assuming isearch will be available throughout Mozilla. I hope so!


    
    

    
  
> A proper Accel shortcut is needed to make it usable outside the browser (e.g.
composer). That's assuming isearch will be available throughout Mozilla. I hope so!

I didn't think of that - good idea. We can put it in the menus too then, it will
be more discoverable that way.

    
    

    
  
Ok, I haven't actually played with this (I'm on Mac ... still no Mac build?),
but here's sort of how I'd expect it to work:

-- User chooses Edit->Find Interactively or presses cmd-shift-F (for example)

-- A thin (1 text-line high, like the Personal Toolbar) search toolbar appears,
that says "Search this page for:" and has a text field, and focus is
transferred to the text field

-- User types "modern" (for example)

-- All occurrences of "modern" on the page are highlighted (google-cache-style)
and the first occurrence is selected.  (These are updated after each keypress.)
In addition to highlighting, the words could get bigger, like Xerox PARC's
browser (http://www.parc.com/solutions/enhancedthumbnails/)

-- To go to the next (or prior) occurrence of "modern", user chooses Edit->
Find Again or presses cmd-G (maybe cmd-shift-G to search backwards).

-- In addition to selecting the text, if that text is part of a link, that link
gets the dotted-outline-thingy, so pressing return/enter follows the link.

-- When I'm done searching, I can choose Edit->Hide Interactive Find (same
menuitem, but its name has changed), or press cmd-shift-F (escape is taken,
right?), and the toolbar disappears.  Focus is back on the web page, so I can
scroll with the up/down arrows.

Come to think of it, up/down should still scroll the page when isearch is
being used.

-- Since the bar is going to take up the whole width anyway, and nobody's
going to use all of it for their search text, you might want to put "Prior"
and "Next" buttons on the right side, with tooltips saying what their keyboard
shortcuts (e.g., "cmd-G") are, to make this more discoverable.

Comments are more than welcome.  (Is this more or less how it really works?)

    
    

    
  
Just filed bug 157772 -   Accel+Shift+G should find-previous.
I agree, Accel+Shift+F is a good shortcut to start incremental text find.
I also like the idea of a textfield in the toolbar somewhere, but I'm not sure
exactly where it would go. There are 2 ways I could see it working:
1) It could either pop there when you started using one incremental find or type
ahead link find
2) The text field could always be there. It could even have a label like this:
Fi_n_d: ---------
Then it would be very discoverable that Alt+N would start the find.
It could even have a checkbox:
[x] _L_inks only
Then it would also be discoverable that Alt+L would toggle that state.
Of course, screen real estate seems to be a problem.

    
    

    
  
I like having the feedback in the status bar, where it doesn't take up any extra
real estate.  Though having it temporarily pop up over the location bar might be
okay ... but please don't add another toolbar that shows up and then makes me do
an extra action to make it go away.  If it does that, then what's the point vs.
just using the find dialog?

Re Ken's comments: highlighting everything and selecting current sounds cool, as
long as it's easy to tell the two apart.  Vim does this (highlight all instances
of the found text) and sometimes it's difficult to find the cursor because of
all the highlighting scattered around the page.

    
    

    
  
Typeaheadfind activates when an <isindex> text field has focus. Examples:
http://www.amherst.edu/cgi-bin/finger
data:text/html,<isindex><a href="http://mozilla.org/">mozilla</a>

    
    

    
  
it too like the way vim highlights all matches, but it would be easier on the
eyes if it used a more subtle highlight color than highlighter yellow :)

    
    

    
  
> it too like the way vim highlights all matches, but it would be easier on the
eyes if it used a more subtle highlight color than highlighter yellow :)

I'm not planning to work on that for now - it's a major change. We can revisit
that after we get the basics done.

    
  
Blocks: 157788

    
    

    
  
ok, i opened up bug 157788 to deal with the desire to have isearch highlight all
matches

    
    

    
  
I have a solution for the <input type=file> and <isindex> problems, but I am
disturbed by it.

Normally I get the event target of the keypress event via:
 aEvent->GetEventTarget(getter_AddRefs(domEventTarget));
 domNode = do_QueryInterface(domEventTarget);

You would think that would give me the correct event target for the isindex or
file input control.

However, I have to get the correct node by doing this:
  // Using the focus controller gets the correct event target
  nsCOMPtr<nsIFocusController> focusController;
  doc->GetFocusController(getter_AddRefs(focusController));
  if (focusController) {
    nsCOMPtr<nsIDOMElement> focusedEl;
    focusController->GetFocusedElement(getter_AddRefs(focusedEl));
    if (focusedEl)
      targetNode = do_QueryInterface(focusedEl);
  }

This fixes the problem. Anyone know why?

    
    

    
  
Maybe using GetOriginalTarget() on the event would be helpful here...

    
    

    
  
Thanks jst, this works:

  nsCOMPtr<nsIDOMNSEvent> nsEvent(do_QueryInterface(aEvent));
  if (!nsEvent)
    return NS_ERROR_FAILURE;
  nsCOMPtr<nsIDOMEventTarget> domEventTarget;
  nsEvent->GetOriginalTarget(getter_AddRefs(domEventTarget));


    
    

    
  
Checked in some now code. New Windows XPI's also up at 
http://www.mozilla.org/projects/ui/accessibility/typeaheadfind.html

This has changed:
- Type a ' or " before your string to search only links. Type / before your
string to search all text. Otherwise it uses your linksonly pref.

Still to do (if it's not on the list, assume it's not part of my current plans):
    * Code Warrior project files, mac installer (to get it working manually,
pull extensions/typeaheadfind and build it)
    * When a match doesn't exist that's already visible, make it go forward from
current position, then wrap to top. It currently restarts at the top.
    * The status bar messages don't include the link target - unfortunately this
isn't as easy to fix as it should be.
    * Draw a box around the selection when in typeaheadfind mode, erase the
drawn box when the mode ends
    * Need nsITypeAheadFind::FindNext(), FindPrev(), StartNewFind(),
CancelFind(), IsActive(), DisableInWindow(), EnableInWindow() etc.
    * Make Accel+Shift+G find previous, even for regular find (bug 157772)
    * In typeaheadfind mode, steal Accel+G/Accel+Shift+G (find next/prev) and
make it respect the current links only setting. This will also allow us to
prevent our find settings (wrap=true, case sensitive=false, backwards=false,
etc.) to not infect normal find.
    * In Linux you currently need to manually focus the content area before it
will work
    * Add type ahead text find and type ahead link find in menus, with / and '
as accelerators.
    * Require that leading / or . be used in message view pane for mail, because
it conflicts with keybindings there.

Future:
    * Have it be able to search alt/title text on tooltips on img links, tooltip
would popup with found text highlighted.

Questionable:
    * Search labels or button text?
    * Use Accel+Shift+F (attached to a menu item) to activate all-text find in
Composer. Make sure nsITypeAheadFind provides interface needed for this.


    
    

    
  
> I agree, Accel+Shift+F is a good shortcut to start incremental text find.

> * Use Accel+Shift+F (attached to a menu item) to activate all-text find in
> Composer. Make sure nsITypeAheadFind provides interface needed for this.

This is already used by Tools > Search the Web in Navigator and Tools > Search
Messages in Mail/News.  If it's added just for composer, wouldn't that be a
little weird?  I think we should have a common shortcut key across all apps.

> I like having the feedback in the status bar, where it doesn't take up any
> extra real estate.

This is what Borland Delphi does for its incremental search (Ctrl+E btw), and
it's very nice.  Unobtrusive but still visible.

> * In typeaheadfind mode, steal Accel+G/Accel+Shift+G (find next/prev) and
> make it respect the current links only setting.

I like this a lot.  Again to use Delphi as a reference, it does the same thing
and makes searching repeatedly very quick.

    
    

    
  
Could this be breaking accelerator keys in mailnews? I.e. go and read an email,
focus the email message and press 'm' to mark/unmark the message as read. That
used to work, now mozilla just beeps at you (with this enabled)...

    
    

    
  
Re using the status bar for this: is it just me, or is the status bar completely
worthless?  All it shows are "Loading..." (in some form or another), the infamous
"Document: Done (10 secs)" -- both of which you could figure out by looking at
the huge M icon -- or the URL under the cursor, which (for reasons that escape
me) is not shown in the URL bar (like OmniWeb does, for example).

So for the record I was suggesting a new space for interactive-search because I
was thinking (hoping) the status bar as it is today would just die.

    
    

    
  
Dean, nice catch. I just added Accel+Shift+F to the keyboard list at:
http://www.mozilla.org/projects/ui/accessibility/mozkeyplan.html

Jst, that's right - it still messes up in mailnews. I'll fix it so that you have
to preface it with / or ' (all text or links only) for it to get turned on, when
in mailnews.

If we want typeaheadfind to work in composer, we'll have to find an accelkey to
do it with. Perhaps it's not 100% necessary for it to be the same key as in
browser and mailnews, since we want to use the single / or ' key to activated it
in the browser.

    
    

    
  
Ken, the status bar is quite useful, for example when you want to see where a
link goes. Does it go to an external site or within the current one?

There seems to be a bug with typeaheadfind where the status information isn't
showing up for some people, but it is for others.

Another bug with our status display is that it only shows what you've typed, it
doesn't also show the link pointed to when you're focused on a link.

    
    

    
  
> If we want typeaheadfind to work in composer, we'll have to find an accelkey to
> do it with. Perhaps it's not 100% necessary for it to be the same key as in
> browser and mailnews, since we want to use the single / or ' key to activated it
> in the browser.

This sounds horrible!  I'm not an User Interface expert, but it seems to me that
randomly changing the keyboard shortcut depending on what window you happen to
be in defeats the purpose of accelerators to begin with.
I don't know any application that does this.  Just try to imagine using one that
did, I suspect most people would quickly give up on the keyboard entirely.
Please, please make it a propper Accel shortcut *everywhere*.  If Accel+Shift+F
is taken use something else, it's still much better than the alternative.



    
    

    
  
I've read most post about the accesskey and came up with the following:
1. A simple accesskey like Ctrl+E, Ctrl+F (or Ctrl+I but this is Page Info)
2. The same key should activate search next occurance (makes it easier to use)
3. For reverse use sift and the key (like Ctrl+Shift+E)
4. I prevere the use of '/' as a toggle between text and links-only
5. Don't make it auto active (without the hotkey)

    
    

    
  
> 1. A simple accesskey like Ctrl+E, Ctrl+F (or Ctrl+I but this is Page Info)

Ctrl+E is, unfortunately, used for Edit Page in the browser.  It would be nice
to have a one-handed shortcut, as I can see myself using this a lot.

> 2. The same key should activate search next occurance (makes it easier to use)
> 3. For reverse use sift and the key (like Ctrl+Shift+E)

I prefer using the already-established shortcut keys for Find Next/Previous. 
After all, this is just another way of entering a search term, just like
entering text in the Find dialog.

> 5. Don't make it auto active (without the hotkey)

I agree.  This may prove confusing to users if they accidentally discover it.

    
    

    
  
> I don't know any application that does this.

Yeah, but browser and editor really _should_ be separate applications.  It would
be good to start moving in that direction... (discussion of that should go to
the newsgroups, however).

    
    

    
  
> Yeah, but browser and editor really _should_ be separate applications.

Regardless, we should try to keep the shortcut keys for the different apps
consistent for similar functions.  It annoys me to no end, for example, that
Word and Excel don't have the same shortcut keys for Find Again.

    
    

    
  
Ever since enabling this I've been getting random lockups where Mozilla spins
using 20% CPU and stops repainting. I have to kill it each time that happens.

    
    

    
  
Ian, I've gotten a couple of random lockups too. If you can reproduce it in the
debugger and get a stack trace that would help a lot.

The point about type ahead find for links is that it's supposed to be more
convenient than using a mouse to activate links. An Accel+Shift combo is too
hard to type. We could use Accel+J, but it's the last keystroke available in all
the apps - that means the next feature someone designs will be screwed out of a
necessary keyboard shortcut. That's the reality, philosophy aside. So, if we can
at all avoid using up the last globally available hotkey, I think we should.

I also don't think users will be confused if it auto activates, but maybe we'll
have to do some testing. I think it would be hailed as a usability improvement
in Gecko-based browsers.

    
    

    
  
Ian, Aaron: Regarding your lockups, neither of you have http pipelining enabled,
right? If so, that tends to cause hangs on its own (bug 146884).

    
    

    
  
I'm pretty sure I found the cause of Ian's lockup. I've checked in the source,
I'll let people know when the new xpi is up.

    
    

    
  
Aaron, I agreed with you initially about link search not requiring an
accelerator, but now I think that's impossible. The problem was pointed out in
comment 83 but seems to have got lost in the noise...

HTML 4.0 lets the page author assign shortcuts with the "accesskey" attribute.
See http://www.w3.org/TR/1998/REC-html40-19980424/interact/forms.html#adef-accesskey

An example taken from the reference:
  <LABEL for="fuser" accesskey="U">User Name</LABEL>
  <INPUT type="text" name="user" id="fuser">
This would make the "u" key a shortcut to a form field in the page.


    
    

    
  
Pedro, accesskey="u" means that Alt+U (or whatever modifier you have under
ui.key.generalAccessKey) would be used to activate that element.

    
    

    
  
> Pedro, accesskey="u" means that Alt+U (or whatever modifier you have under
> ui.key.generalAccessKey) would be used to activate that element.

Ah, I didn't read the part that said implementations were allowed to tack a
modifier in front of the access key. My fault.
I still have to reply to that post about lack of available keys for incremental
find. I'll do that when I have the time to write something coherent :)


    
    

    
  
Here's the keyboard planning FAQ (you need to read this to see why we don't use
certain keys that you think would be available):
http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html

Here's the current list of keys we use (I keep this updated, so if it's missing
something let me know):
http://www.mozilla.org/projects/ui/accessibility/mozkeyplan.html

The idea was brought up to use 
Accel+/ for find in all text
Accel+' for find in links

That way we could be consistent across apps. I would still want the browser to
allow simple typing to start link find mode automatically (or whatever the
current linksonly pref says).

    
    

    
  
> The idea was brought up to use 
>     Accel+/ for find in all text
>     Accel+' for find in links


Sounds briliant :)

Both are easy to type without looking.
They're physically near, which is good for similar functions
    think F=find, G=find aGain
       or C=copy, X=cut, V=paste
The / is the same key as is used in vi (and derivatives).

I'm all for it!
-matt



    
    

    
  
...for US-keyboards that is correct. For a Swissgerman keyboard this equals to
Accel+Shift+7 and Accel+' (' is next to the 0). That's not too bad either but I
would like to have some feedback from other users with non-US keyboard layouts.

    
    

    
  
Awkward entry on non-English keyboards is exactly why we don't usually use
accel+punctuation.

    
    

    
  
Yes, that is one of the things I was going to complain about. In my experience
any keys other than letters and numbers tends to get shuffled around a lot in
different languages. A character that's easily accessible in one keyboard will
be buried under a horrible combination in another.
Thanks for the pointers to the keyboard stuff, I'll check them.


    
    

    
  
Is there any way to make the shortcut configurabe?

I really want to use Crtl-S to search.  I assume I'm the only person on earth
that would want to throw away "Ctrl-S" to save in favor of "Ctrl-S" for search.
 But I'd really like it to be configurable...


    
    

    
  
> any way to make the shortcut configurabe?


I'm guessing "no".

Some apps have user-configurable key bindings, but mozilla isn't
set up for that, and doing it for specific commands only is a sure
way to frustrate folks.

You wanted "s", and maybe my grandmother would to. Then when my
grandmother called me for help with something, I might direct her
to save something and she'd be in isearch instead. This would be
difficult to debug over the phone, ya know? At least my grandmother
isn't paying for computer support, but lots of other folks do.

If there were app-wide key-binding configuration, there could also
be saved configs, and "return to default" which would be handy for
the helpdesks in the world.

...but I think many things would have to be re-worked for mozilla
to have user-configurable key bindings...

-matt

    
    

    
  
Just checked in support for Accel+Shift+G to find previous. It currently only
affects type ahead find, not regular find.

Also, Accel+G and Accel+Shift+G now respect whether you're in links only type
ahead find mode.

    
    

    
  
I had a lockup, I then forced a talkback report by sending SIGSEGV to the
process. This is the id: TB8449576G

    
    

    
  
I had a lockup today too, I didn't immediately connect it with this code, but it
could be...

The stack from TB ID 8449576 shows:

IsMemberOf()
nsFind::IsBlockNode()
nsFind::GetBlockParent()
nsFind::Find()
libtypeaheadfind.so + 0x4e2d (0x40672e2d)
libtypeaheadfind.so + 0x4296 (0x40672296)
nsEventListenerManager::HandleEvent()
GlobalWindowImpl::HandleDOMEvent()
nsDocument::HandleDOMEvent()
...

    
    

    
  
Mozilla has had configurable key bindings for a long time.  See
http://www.mozilla.org/unix/customizing.html#keys

Aaron, will this binding be done in such a way that it's accessible to XBL and
thus configurable?  What's the command?

    
    

    
  
I think the lockups have been solved. Has anyone experienced a lockup with the
stuff that got uploaded to this afternoon?

Akkana - yes, they will be legit binding - complete with menu items and a
cmd_linkTypeAhead and cmd_textTypeAhead entries in HTMLBindings.xml.



    
    

    
  
Could we have a summary of what is implemented? Are the hidden prefs gone?
What's happened with the timeout? What are the shortcut keys? Cheers!

    
    

    
  
Ian, the web page for this feature is at
http://www.mozilla.org/projects/ui/accessibility/typeaheadfind.html

I've been keeping that page updated.

    
    

    
  
i just installed the XPI on my new install of mozilla (2002071813) and moz
crashed on the first exit after install.  (i saw this previously with an older
build, as i commented abouve - talkback id : TB8258875X) ... the talkback id for
this crash is TB8478323H

    
    

    
  
Ok, taking up the keyboard shortcuts issue again...

I propose incremental find be assigned to Accel+Shift+F.  But wait, that's
already used to bring up the Search Messages dialog in Mail... well, just change
that binding.  I believe this is correct (and feasible) for the following reasons:

- The guidelines recommend grouping related operations under Accel/Accel+Shift
shortcuts. Find and Interactive Find are certainly closely related. And F is
next to G (used for find next) which is good.
- There is a small set of operations (mostly stuff under File and Edit menus)
that is available throughout the application. These operations always have the
same keyboard shortcuts. I believe Interactive Find is in this category.
- Changing the conflicting binding in Mail/News should not prove a problem. A
quick look gives 18 available letter shortcuts in Mail/News, plus 6 Accel+letter
and 15 Accel+Shift+letter. Besides it's not like Accel+Shift+F readily
identifies with an operation called "Search Messages" anyway.

That's it. I'll shut up about keyboard shortcuts now.

    
    

    
  
Ok, this is going to sound really smart or really stupid (or somewere
in between): I always thought that incremental/interactive search, done
properly, would replace the klunky search that Mozilla has now.  So we'd
just steal accel-F.  Providing users with two ways to do something has
been shown to be a pretty good way to slow them down, IIRC.  (If I gave
my boss Moz, and pulled down the Edit menu to do a search, his eyes would
see "Search-type-1" and "Search-type-2", and he'd spend a lot more time
trying to figure out what the heck they were than if he'd been given only
old-klunky-search in the first place.)

In any event, which key on the keyboard you pick is probably (1) not
outrageously important right now (when, for example, this isn't even
available on Mac builds), and (2) pretty easy to change later if you
change your mind.

    
    

    
  
We need to keep Ctrl+F.
1. Sometimes you need to be able to paste a find string in
2. It has more options, case sensitive, wrap, back, etc.
3. Who knows, maybe the find dialog will allow regular expressions someday

    
    

    
  
Whoa whoa whoa!

> 1. Sometimes you need to be able to paste a find string in

Can't isearch do this?  Back in comment 91 I said we should have a text field
because, well, since about 1984 if you want the user to enter some text in a
GUI application, you use a text field.  And if there's a text field, you can
paste text into it.  We shouldn't make up new user-interface primitives just
because.

> 2. It has more options, case sensitive, wrap, back, etc.

The wrap checkbox there was talk of getting rid of.  Backwards search, I
thought you could do with isearch (or if not, we better).  In fact, isearch
appears to have picked up a strange feature ("search links only"?) that the
search dialog doesn't have, so "more options" is not simply the domain of
klunky-search.

Case-sensitive searching, I don't know.  Maybe we could add a checkbox.  Maybe
we could do what search engines do (case-sensitive if-and-only-if there are any
capital letters).  Maybe somebody else has a better idea.  I like to think that
we could come up with something better than "Let's have 2 search modes with
completely different feature sets and let users try to figure it out".

> 3. Who knows, maybe the find dialog will allow regular expressions someday

"Who knows, maybe [we'll add geek-feature X] someday" is not a good reason
to confuse and slow down all of your users today -- that is, even if isearch
and regexps were completely exclusive, and I don't see how they are.

    
    

    
  
Ken, okay you make some good points.

However, are you sure that a lot of users will be suddenly comfortable with the
new find? I see this more as a feature for advanced users.

It's kind of like the way mailnews has quick search, and advanced search.

I just don't sure it's a good idea to pull out the old feature, but then again
the decision doesn't really rest with me. I think of this as more of a quick
navigation feature.

    
    

    
  
I just noticed something interesting about the bug where you have to manually
click into the window first, before it will work.

At least in Windows, it only occurs when the URL you're loading is from file://
If it's an http:// document things work right away.

Anyone notice this on Linux?

    
    

    
  


  
Ready for review - pls review entire text, not just + lines

        Attachment #90515 -
        Attachment is obsolete: true

    
    

    
  
You often have to click in the document anyway on linux, due to bug 141295:
focus in content area is erratic (timing?).

    
  
Depends on: 158743

    
  
Depends on: 158752

    
  
Depends on: 158754

    
  
Depends on: 158756

    
  
Blocks: 158743, 158752, 158754, 158756
No longer depends on: 158743, 158752, 158754, 158756

    
  
Blocks: 158757

    
    

    
  
Typeahead is not working in the latest trunk nightlies.
I'm using 2002072208 on Win2000, but people on mozillazine have reported this
also for 2002072004 on Windows and Linux.


    
    

    
  
Pedro, is it not working when you build it yourself, or when you install the 
xpi?

    
    

    
  
I'm using the builds posted to ftp.mozilla.org and the XPI installed from your page.


    
    

    
  
I added the current XPI to Mozilla 1.1b (2002072204 on Win2K) and it does not
work. It apparently does nothing. No errors. No feedback. No find. I went to a
page and tried typing text included in a link. I also tried clicking in the
window, but that didn't help. Regular find works in the same build.

I used incremental find in an earlier build and it was nice and convenient for
finding links. Thanks!

Out of curiosity, how should it behave on a page with an HTML form? If a form
field does not have focus should you just be able to use it? Perhaps that's what
it did with earlier builds. My concern is that I may think a field is focused
and start typing and instead end up with incremental find. This could be
confusing if I type text, press Enter, and activate a link. I need more testing
with this to see if this would be likely to happen. I suspect not. If we want to
block on pages with forms, it would seem easy enough to check document.forms.length.

    
    

    
  
It doesn't conflict with forms - if you're in a text field, type ahead find 
will not automatically start when you type.

The XPI probably doesn't work right now because I haven't pulled and built in a 
while. One of the interfaces it uses must have changed since I last pulled and 
built. I'll try to put a new one up soon. In the mean time, you can build and 
test it in a debug build by doing a make in extensions/typeaheadfind. Or you 
can try to use the XPI for Mozilla 1.0/Netscape 7.0 instead, instead of working 
with the trunk stuff.

    
    

    
  
Aaron: So, are you suggesting using the Mozilla 1.0/Netscape 7.0 XPI with
Mozilla-trunk, or using it with Mozilla 1.0?

    
    

    
  
You have to use the trunk XPI with the trunk, and the M1.0/NS7 XPI with 
M1.0/NS7. Try the M1.0/NS7 option.

    
    

    
  
> You have to use the trunk XPI with the trunk, and the M1.0/NS7 XPI with 
> M1.0/NS7. Try the M1.0/NS7 option.

I haven't made a Linux XPI for the branch yet, because the code doesn't seem to
be checked in on the branch, and copying the trunk source directory to a branch
tree doesn't build (some APIs must have changed).  Do you have a patch stashed
somewhere to make this code build on the branch?  Does anyone care enough about
getting a Linux branch xpi that I should work through the errors and make it
build?  I don't mind doing that if there are customers, but if nobody wants it
then it's not worth spending time on.

(I'm not using the xpi myself for daily browsing because I was hitting the
problem stealing input from certain form controls, otherwise I'd care more about
a branch XPI for my own use.)

    
    

    
  
> (I'm not using the xpi myself for daily browsing because I was hitting the
> problem stealing input from certain form controls, otherwise I'd care more
> about a branch XPI for my own use.)

That is fixed - it no longer steals input from form controls, AFAIK.

    
    

    
  


  

        Attachment #92220 -
        Attachment is obsolete: true

    
    

    
  
I'll post review comments a bit at a time, since I keep getting distracted in
the middle of reviews.  Hope that's okay.  First installment:
Please get rid of this unused variable, which causes a compile warning:

nsTypeAheadFind.cpp: In method `nsresult nsTypeAheadFind::KeyPress 
(nsIDOMEvent *)':
nsTypeAheadFind.cpp:564: warning: unused variable `PRBool isLinksOnly'


    
    

    
  
Typeaheadfind activates even when focus is in a <select> (collapsed drop-down or
listbox).  Example: http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser.

Backspace goes back if I use backspace to delete the first character I typed.

    
    

    
  
Rather than continually posting patches, Akkana and I are going to work on the
r= using the checked in "not part of build" code. Comments from everyone on the
code are welcome :)

    
  
Keywords: nsbeta1

    
    

    
  
r=akkana on the code Aaron currently has in his tree, including the patches for
bug 158754 and bug 158756, plus some other changes we discussed while going over
the code.

There are some minor configure.in changes to add this to the extensions=all
list, and we still need mac project files.

    
    

    
  
Comment on attachment 93432 [details] [diff] [review]
Latest changes/additions - includes some ifdef'd out code that will be used later for changing the appearance of selection when type ahead find mode is on.

Latest type ahead find code is in tree (not part of build). Ready for sr=.

        Attachment #93432 -
        Attachment is obsolete: true

    
  
Depends on: 161846

    
    

    
  
Just filed bug 161955:

"RFE: When link is focused, Accel+T to open link in new tab, Accel+N to open
link in new window"

I believe that would really enhance type ahead find - you could type in a couple
characters to find a link and hit Accel+T or Accel+N to get it in a new tab or
window.

Seeking opinions in the bug.

    
  
Blocks: 161960

    
    

    
  
I've updated the XPI for Windowss again. It works with trunk builds after 8/10/02.
http://www.mozilla.org/projects/ui/accessibility/typeaheadfind.html.

This one has the nice color change when type ahead find mode gets turned on.

    
    

    
  
*** Bug 105565 has been marked as a duplicate of this bug. ***

    
    

    
  
Aaron: I'm not sure what's going on, but I haven't been able to get the XPI to
work for me since about July 12th. 

I'm using 2002081504 (Trunk) on Win2k with the windows-trunk XPI posted at the
URL above. And, I've added these prefs to my prefs.js:

user_pref("accessibility.typeaheadfind", true);
user_pref("accessibility.typeaheadfind.linksonly", true); 
user_pref("accessibility.typeaheadfind.timeout", 0);

(I set that last one to 0 to disable the timeout). 

At any rate I go through these steps just about every day: install the latest
nightly build, install the XPI, shutdown Mozilla, ensure that the prefs are
intact, and restart Mozilla. But, when I start typing text (that I know exists
in the page), nothing happens :(.

    
    

    
  
Alex, can you try building it yourself to see if it works? It's hard to get the
right xpi-trunk combination because it's got binary files. Go to
extensions/typeaheadfind and run make.

- Aaron

    
    

    
  
Aaron: Unfortunately, I'm on a Windows machine (without a compiler). Hmm, maybe
I'll just wait for the finished version :-/.

    
    

    
  
Comment on attachment 95712 [details] [diff] [review]
Adds typeaheadfind to default build (except on Mac, which will come later)

sr=jst for this part, but don't you need to list the new Makefile.in's in
extensions/typeaheadfind in allmakefiles.sh too?

        Attachment #95712 -
        Flags: superreview+

    
  
Depends on: 141295

    
    

    
  
Comment on attachment 95775 [details] [diff] [review]
Same configure.in changes in patch, but also includes allmakefiles.sh  changes

You need something to reference the MAKEFILES_typeaheadfind variable in
allmakefiles.sh too, just defining the module doesn't do anything.

        Attachment #95775 -
        Flags: needs-work+

    
    

    
  


  

        Attachment #95775 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 95822 [details] [diff] [review]
Correct configure.in and allmakefiles.sh changes

r=cls on the build changes.  I'd also like to see an sr= since this involves
turning on a chunk of otherwise unused code.

        Attachment #95822 -
        Flags: review+

    
    

    
  
Comment on attachment 95822 [details] [diff] [review]
Correct configure.in and allmakefiles.sh changes

sr=jst

And for the record, I've sr'ed all the code that this change will turn on in
the build.

        Attachment #95822 -
        Flags: superreview+

    
    

    
  
It's checked in, but for now you'll have to turn it on with the pref:

user_pref ("accessibility.typeaheadfind", true);"


We'll turn it on by default soon, if all goes well.

    
    

    
  
When the preference is enabled then pressing F3 hangs the browser at any time
other than when some searched for text is active (highlighted green). Should I
report this as bug elsewhere or is here the right place?
Windows 2000, build 2002082008 

    
  
Depends on: 163905

    
    

    
  
Thanks David - I filed bug 163905
"[typeaheadfind] F3 hangs browser after selection returns to normal color"

Please file other type ahead find bugs under the "Keyboard Component", I'm the
default owner for that.
We'll turn this into a meta bug for other type ahead find problems.
Also please put the string [typeaheadfind] to start the bug summary.

    
  
Depends on: 163913

    
  
No longer blocks: 154414, 157788, 158743, 158752, 158754, 158756, 158757, 161960

    
  
Depends on: 154414, 157788, 158752, 158757, 161960
Keywords: meta

    
    

    
  
Okay, I have patches needing review in bug 163913 and bug bug 163905.
If someone can r= those for me I'll get them in asap.

    
    

    
  
for internationl, I think we need to test in the folloiwng cases
1. with the pref turn on IME operation still work inside html form
2. with the pref turn on, we can search different keyboards layouts also work
(can find the text)
  a. Different layout for ascii key- in German case, y and z swap from English
  b. Dead key process can match up the key (searching the accent text)
  c. non ASCII keyboard (Greek, cyrillic, hebrew, etc)
3. I am not sure what we should do with ime, since ime require additional pre
editing, I don't think it could work with type ahead, but
  in the type ahead mode, if we turn on IME, we should not see anything
abnormal, nothing should happen in that case. We should not see ime window popup.
4. on Mac, we should test with option key, for example, does option m match the
greek mu ?
5. In addition, I think we should test the following case: does the type ahead
match text encoded in numerical entity (hex and dec), or named entity (e.g.
&trademark; )

    
    

    
  
Also for i18n, we must test if the case insensitive search works for characters
that are not a-z. For example, if the user types a letter with an accent it
should match something with a capitalized version of the accented letter.
I have already verified that it works fine with right to left text, at least
when I use { unicode-bidi: bidi-override; direction: rtl; } in my
userContent.css to force it on for English.

    
  
Depends on: 164295

    
    

    
  
Is there a way to get typeaheadfind to match a literal slash? I tried typing //,
but the second slash seems to be ignored and it finds nothing. I'm not sure that
this is a big deal, since it can match seemingly any other character.

    
    

    
  
It can find a / or ' as long as it's not the first character.
However, I see what you're trying to do by typing //.
I can fix that to work.

    
    

    
  
Seeking r= for:
Bug 161960 - Accel+G loses typahead search buffer.
Also fixes / and ' so they can be the first character.

    
  
Blocks: 157788
No longer depends on: 157788

    
    

    
  
Sorry, this might be spam, but: the search doesn't seem to work for me at all ...
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020825, 
BuildID 2002082521, downloaded the mozilla-i686-pc-linux-gnu-sea.tar.gz file,
enabled iSearch in the prefs, but nothing happens in my case ... either I'm to
stupid, for that case a better instruction might be needed, or it just doesn't
work in my build ... I didn't find any file, that matches the
*typeaheadfind*-pattern in my mozilla-directory ...
One ore thing to mention: I use a german keyboard
Thanks for your patience :-)

    
    

    
  
My experience is that typeaheadfind is not yet (or no more?) enabled for
installer builds, i.e. mozilla-i686-pc-linux-gnu-sea.tar.gz and
mozilla-win32-installer-sea.exe. I just downloaded a current win32-talkback.zip
and used it parallely to a installer-sea.exe build of the same day with the same
profile. I checked enabling/disabling extensions like MultiZilla (was my first
guess) and plugins, but it seems there is a real difference between ZIPs and
installers, because typeaheadfind worked with the talkback ZIP but not the
installer build. Neither does it (installer) work under my Linux (SuSE 7.3).

    
    

    
  
Sorry, it's not packaged with the installer yet, working on that. It is part of
the default build, but you have to build Mozilla yourself.

    
    

    
  
Here's some bad news:
My checkin last night (08/26, 22:57), which only turned on the pref,
affected tinderbox numbers:

Here are the Luna numbers.
Tp (page load times) - 1091 -> 1113 
TxUl (nav open time) - 1182 -> 1236
Ts (startup times) - 1497 -> 1520



    
    

    
  
Aaron. Sorry, bud, but I think you should turn off that pref now, pending 
investigation of why this has caused performance numbers to degrade 2-4%.

    
    

    
  
I think I have a patch that fixes the perf problem. It's attached to the fix in
bug 161960

    
  
Depends on: 165100

    
    

    
  
Thanks, aaronl for reverting the pref to false in the interim. When you have a 
fix landed in the trunk I (or kerz or barrett) will test the fix for 
performance impact. [Times on the tinderbox appear to reverted to their levels 
from before the regression].

    
  
Depends on: 165315

    
    

    
  
I'd like to make it easier to open links (especially those focused from
typeaheadfind) in a new tab from the keyboard. I realize there's a pref that can
be set, but that's not ideal, in my mind.
I just opened bug 165584 on the subject.

    
  
Depends on: 165626

    
  
Depends on: 165632

    
  
Depends on: 165398

    
  
Depends on: 165665

    
    

    
  
I'm using build 2002083005 on Linux
It appears typeaheadfind is preventing "1st letter" keyboard navigation in
menus.  So I can't open the file menu then press Q to quit anymore.


    
    

    
  
Are there any bug reports filed for the behavior mentioned in comment #189?

I use keyboard shortcuts a lot and this typeahead is eating all my keystrokes. 
Nasty bug...

    
  
Depends on: 166033

    
    

    
  
bug for comment #189 is bug 166033

    
    

    
  
 I would like to navigate using voice recognition.   The search ahead function
described here just doesn't cut it  for doing this.  How many Web pages  are out
there where all the links are titled "click here",  or the images have no alt
tags?!   Too many!    

  The easiest way to do this would be to have an option to turn on link
numbering, and be able to go to  a link by  entering some key sequence and the
link number (  Which would easily come from a voice macro, and is much more
accurate than arbitrary word dictation).
 
Do I need to open up a new feature request for this?   Please tell me I'm wrong,
but none of the link access  bugs I have found seem to contemplate real
accessibility issues for  people with accessibility problems!

    
    

    
  
Rob: you're quite right that this feature doesn't address that issue at all.  if
there's no bugzilla issues requesting the feature you're looking for, then, yes,
you do need to open a new feature request (and please do so, 'cause it sounds
like something that could be good)

    
    

    
  
I completely agree with comment 82. Some people want to use this concept for
searching within the page, and some want to use it for quick keyboard navigation
(linksonly). Personally I belong to the former camp, and as such I am biased and
believe that users would prefer a quick way to search for a string to a search
of the page's links. I can see the other side, though, since searching the links
is analogous to what typing in a MacOS finder window (including the desktop)
does - selects a file which starts with the string you're typing - and I grew up
on the Macintosh. The linksonly mode also is extremely handy for navigation; one
of the only things I use the mouse for anymore is clicking on links. After
careful consideration I have come to agree with the idea of prefix keys (/ and
') which can be used to force one of the modes, since both linksonly and
fulltext searches are extremely handy, and I'm glad there's a preference item
which selects the default. Will a straightforward interface to these preferences
(i.e. via the prefs dialog) be implemented soon?

And thanks to everyone who worked on this and discussed the idea - it's a really
cool feature. Good riddance to that blasted find dialog.

    
    

    
  
Rob, there's already a request for navigating links by number in bug 101689.

As far as preferences and defaults go, we're going to do some end user testing
and see what we learn. I'll keep everyone posted. My preference is that we keep
things as they are, but have an exposed setting for changing what just typing
without a prefix character does.

As far as the bug with eating menu keystrokes goes, I am experiencing that too!
Looking at that issue now.



    
    

    
  
Here's a weird one.  Try to incrementally find 'rfe' on this bug report.  It
can't find the 'r', but has no problem finding 'fe'.

    
    

    
  
Dean, I am seeing that, but only in text-only find.

Well, between that and a couple of other regressions, I decided to turn the pref
off by default again, until I get these issues resolved.

    
    

    
  
wrt comment 196, for me typeaheadfind won't find any of (at least) abgiloruz1 as
the first character, in full search mode. (try 'branch', get 'nch') -> filed bug
166340
Depends on: 166340
Summary: [RFE] Incremental find (like Emacs isearch) → [RFE] Incremental find (like Emacs isearch) (type ahead find)

    
    

    
  
Okay, the problems with menus, text-only find and new documents in the same
window are fixed, some performance improvements have been added, and the pref is
turned back on.

    
    

    
  
Hmm... I've seen an occasional problem where typeaheadfind stops working
temporarily. It thinks it's in a menu. 

To get it working again, do this: right click and then hit escape, then go to
the main menu bar and escap. This will clear that menu state from typeaheadfind,
and it works again.

If anyone can figure out a consistent test case, please put it in bug 166033.

    
    

    
  
Aha, it seems that when you tab away and then tab back, automatic typeaheadfind
gets disabled. You have to type alt or f10, then escape toget it working again.

    
    

    
  
Even more specific, it seems to happen when you let go of the alt key before you
let go of tab, during the Alt+Tab sequence.

    
  
Depends on: 166704

    
  
Depends on: 166712

    
  
Depends on: 166955

    
  
Depends on: 166993

    
  
Blocks: 154414
No longer depends on: 154414

    
  
Depends on: 167022

    
  
Depends on: 167041

    
  
Depends on: 167207

    
    

    
  
Using the 2002090608 installer build on WinNT, type ahead find was downloaded
but not automatically installed. I could make it work by manually extracting and
installing the required files from the XPI. Has somebody else seen this too?
This isn't the intended behaviour, is it?

    
    

    
  
Yes, I should have mentioned that - it's corrected in installers starting on
September 7.

    
    

    
  
this interferes with javascript shortcuts on pages like 

http://labs.google.com/cgi-bin/keys?q=mozilla

Is there a setting by which type ahead find is invoked only if I press a certain
key before the search string. That is, can I set typeaheadfind so that it does a
search for me only if I prepend the search string with either / (for text) or '
(for a link)

Build: 20020907
OS: Win XP

    
    

    
  
Yes it's valid for a page to assign script functionality to the same keys
typeaheadfind uses. These same pages would have a problem in IE Mac, which has a
link find as you type feature as well.

The web page should be able to call event.stopPropagation(), which will keep
typeaheadfind from getting the keystroke. They'd also have to do this if they
wanted to override what spacebar does - which tends to mean page down in most
browsers.

I'm definitely open to other suggestions about this problem.

    
    

    
  
One solution is to have, as Manoj suggests, a keystroke to start typeaheadfind.
 Once started, it would be a capturing listener, not a bubbling listener, and
would cancel the events itself.  This would prevent unwanted interaction with
the page's JS..

    
    

    
  
Couldn't we get rid of the find in page dialog?
Ctrl-F could bring a toolbar in the content area that would offer the same 
typeahead find functionality as in mail/news and adressbook

    
  
Depends on: 167783

    
  
Depends on: 166791

    
  
Depends on: 167921

    
  
Depends on: 168018

    
  
Depends on: 168084

    
    

    
  
Using Mozilla build 2002-09-09-08-trunk, I verified that type ahead works with
Simplified Chinese, English, German, Spanish and French keyboard layouts.

However, it does not work with Traditional Chinese, Japanese and Korean.
Specifically, when Rui and I try to enter some Japanese characters on the Yahoo
Japan homepage (http://yahoo.co.jp/), nothing happens. We do not get any kind of
error messages in the status bar saying word not found, etc. It's as if we never
typed anything. In contrast, we get visual feedback (characters are displayed on
the top left corner of the page) when we search for Simplified Chinese links.
Japanese search does not work even under Japanese XP. 

An interesting problem we noticed was that although nothing seems to happen when
we enter some characters, if we then click in a textfield and attempt to enter
more characters inside that field the characters we entered previously suddenly
appear inside the field. Delete does not work in the textfield as expected after
the reappearance, as it somehow introduces more characters into the textfield.  

    
    

    
  
Type ahead does not work at all for me and never did! What am I doing wrong? I
was always downloading the latest nightly builds, but it never worked there and
today I download 1.2a release and it doesn't work either. Hello? What's going on
here? I was trying to add user_pref ("accessibility.typeaheadfind", true); to my
prefs.js, but it's removed at once when I start up Mozilla and it does nothing
in my user.js file either. I'm using Win98.

Also have you considered, that HTML4 allows you to give a link (ANCHOR tag) a
quick key (a so called accesskey). To quote from the original HTML4 specification:

***********************

This attribute assigns an access key to an element. An access key is a single
character from the document character set. Note. Authors should consider the
input method of the expected reader when specifying an accesskey.

Pressing an access key assigned to an element gives focus to the element. The
action that occurs when an element receives focus depends on the element. For
example, when a user activates a link defined by the A element, the user agent
generally follows the link. When a user activates a radio button, the user agent
changes the value of the radio button. When the user activates a text field, it
allows input, etc.

***********************

Actually Mozilla should rather implement that than a type-ahead find. Such a
find should only be done like in text editors: Via an access key. And not via a
normal key, as such a key could always be used as access key on a HTML page, but
via a combination of a key and a control key. E.g. CTRL+F doesn't turn up a
search dialog, but just puts focus on a type-ahead search line.

    
    

    
  
> but it's removed at once when I start up Mozilla

Sounds like you use quicklaunch and edit while Mozilla is running.

> Also have you considered,

Yes.

> Mozilla should rather implement that

Mozilla has implemented that for a good while now.  At least a year, probably
more.   It's alt-key (since ctrl-key is used for browser keyboard shortcuts). 
See also comment 117 through comment 119 in this very bug.

    
    

    
  
> Sounds like you use quicklaunch and edit while Mozilla is running.

I never run quicklaunch and I certainly don't edit the file while Mozilla is
running. Despite that release note of 1.2a says it's enabled by default, isn't
it? It simply doesn't work for me and never did since it was added to the trunk.

>> Mozilla should rather implement that
>
> Mozilla has implemented that for a good while now.  At least a year, probably
> more.   It's alt-key (since ctrl-key is used for browser keyboard shortcuts). 
> See also comment 117 through comment 119 in this very bug.

The Alt-key can't be used for that purpose in practice, it's already used for
the menus. E.g. if I hit ALT+E the Edit menu opens. If I hit ALT+F, the file
menu opens. This is BTW like all Windows application works (pressing only ALT =>
focus menu and allow it to navigate with arrow keys; pressing ALT and a letter,
open the menu that starts with that letter). But this means that F, E, V, G, B,
T, W, H, D and Q can't be used anymore as accesskey.

    
    

    
  
Maybe you should try it or something, huh?  If you have an "f" accesskey defined
in the page, Alt-f will trigger the accesskey instead of opening the menu.  This
is a much better alternative than having no good way to trigger the Find dialog,
and the menu is accessible as "alt f" (press alt, release, press f).

    
    

    
  
> If you have an "f" accesskey defined in the page, Alt-f will trigger the 
> accesskey instead of opening the menu.

Which means Mozilla behaves differently than any other Windows application there
is, including Java application when getting executed on a Windows platform.
People that are used to access menus via quick-key navigation will not be happy
to be taken somewhere when they click ALT+E to access the edit menu. Especially
ALT+W is popular, because it's used by all applications that have a Window menu.


But still, I don't know of any text editor that has type-ahead for any letter
you type. How does it work in EMACS (which is mentioned hundreds of times here)?
AFAIK you first have to "start" an I-Search (that's how it is called, right?). I
see no reason why this should be different in Mozilla.

Another issue is that I'm against adding any functionality that you can't
disable and NO, modifying JS files by hand does not count here. If it is a
preference, it must have an entry in the preferences menu. E.g. I'm using mouse
gestures in Mozilla and it creates a new tab in the preferences. As long as a
feature has no preference entry to disable it, it's not ready to be included in
the default build.

And finally, the question remains whether it actually is in the default build,
because on my system it doesn't exist, neither with the nightly build of today,
nor with 1.2a.

    
  
Depends on: 168135

    
    

    
  
> But still, I don't know of any text editor that has type-ahead 
> for any letter you type.

...and that's good because in a text *editor* you are supposed to *enter* text
above all. No use in continually searching around.
In a browser there are only text fields for entering etc. and these only get
text when they are focused, anyway.

> I never run quicklaunch and I certainly don't edit the file 
> while Mozilla is running.

Well, it works here with trunk build 2002091108. Maybe try again with user.js
and a complete restart of windows (to make sure mozilla was shut down).
Then click somewhere on a html page and start typing. Watch your status bar.

    
    

    
  
> Which means Mozilla behaves differently than any other Windows application
> there is

except, for example, Internet Explorer, which behaves exactly the same way -
access keys on the page are supposed to override the standard functions. try
visiting http://www.htmlgoodies.com/tutors/accesskey.html with IE and mozilla.

> But still, I don't know of any text editor that has type-ahead for any letter
> you type. How does it work in EMACS (which is mentioned hundreds of times here)?
> AFAIK you first have to "start" an I-Search (that's how it is called, right?). I
> see no reason why this should be different in Mozilla.

if you've got a specific reason why it shouldn't, file a bug on it.

> Another issue is that I'm against adding any functionality that you can't
disable [without a pref]

I'm not sure it's such a great idea either, but whether we're against it or not
isn't relevant (and bugzilla comments certainly aren't the place to discuss all
this)

> And finally, the question remains whether it actually is in the default build

it is. works fine for me. maybe something got screwed up in your install - try
uninstalling, deleting your mozilla folder, and reinstalling? (and no this isn't
acceptable in general, but we're using alpha builds here)

    
    

    
  
Hi,

I've a lot of links in my personal toolbar folder. I want to access them with a
shortcut too but didn't find anyone yet. What about Type Ahead for my personal
toolbar? Probably with another leading character or just always.

Keep up good work!

Stephan

    
    

    
  
Can we get this same behavior for <select> boxes?

Currently, select boxes will jump to the first selection that starts with
the character you type.  If you type the same character multiple times, it
will cycle through all of the entries that start with that character.

What is missing is matching on the first N characters, instead of only the
first character.  I like the type-ahead behavior better, and why not make
the behavior consistent between the two?

    
    

    
  
Brad Garcia:

See bug 79035 for "[RFE] Autocomplete for drop-down boxes"

    
    

    
  
> I've a lot of links in my personal toolbar folder. I want to access them with a
> shortcut too but didn't find anyone yet. What about Type Ahead for my personal
> toolbar? Probably with another leading character or just always.

Try Alt+B P and then the first letter of the bookmark. You can also repeat  the
first letter to iterate through items that start with that letter. If there's
only 1 item that starts with that letter, it will just activate the bookmark.
Otherwise it will wait for Enter.

    
  
Blocks: 168281

    
  
Blocks: 168286

    
  
Blocks: 168289

    
    

    
  
>> But still, I don't know of any text editor that has type-ahead 
>> for any letter you type.
>
> ...and that's good because in a text *editor* you are supposed to *enter* text
> above all. No use in continually searching around.
> In a browser there are only text fields for entering etc. and these only get
> text when they are focused, anyway.

But Mozilla has editors (webpage composer, mail & news composer), so if I want
to have the isearch there, I first have to press some shortcut to enable it. I
think such a new feature should work everywhere in Mozilla (XP feature) and it
should work everywhere the same, as otherwise users using it mainly in the mail
composer will wonder why it doesn't work the same way in the browser and people
using it mainly on webpages will not know how they could do it in an editor
window. CTRL+F is always CTRL+F and always works the same in way, doesn't it?
It's important that one and the same application doesn't work differently in
different windows.


> works fine for me. maybe something got screwed up in your install - try
> uninstalling, deleting your mozilla folder, and reinstalling?

I'm not a Mozilla newbie, I used already Mozilla before version 0.6 (and always
nightly builds); I know when Mozilla is loaded in my memory or running and when not.

> (and no this isn't acceptable in general, but we're using alpha builds here)

An alpha release of a software means all features have already been implemented
the way they are supposed to be in the release version (so if iserch shall have
a preference in 1.2 release, it already should have a preference in 1.2a). Alpha
only means that the build is not guaranteed to be stable or to be used by
public, but only by testers. Beta is the same as alpha, but means that meanwhile
a level of stability has been reached, that means now everyone can test it. You
don't add/remove features or alter the GUI of an application between alpha,
beta, RC and final release. You only fix bugs and make sure everything is
working like supposed to be working.

And isearch is not working for me. You make a handstand if you like and dance
the happy dance, but when I say it is not working (not at all), it is not
working and there is absolutely nothing at the status bar.

    
    

    
  
Okay, that explains everything. Why is type-ahead finding a component? That
makes no sense to me. For me it's just a browser or XP feature. Oh and if it
already is a component, just like PSM is installed if you select browser only,
type-adhead find should of course be installed, too, as it's part of the browser
functionality (just like PSM).

And the status bar still doesn't do anything, in case it is supposed to do
something. Mozilla jumps to the typed text, but there is nothing in the status
bar. There's always "Done" in my status bar. (and I have enabledt to allow
JavaScript to alter it, although usually I don't do so).

I also don't understand why this isearch is included as a component in the
default browser install, but one still has to download mouse gestures from
Mozdev as browser add-on, even though people have requested mouse gesture in
Mozilla long before the idea to implement isearch has even existed and the idea
to add this to Mozilla was knocked down at once. Even though it's a much cleaner
feature, as it does not need native code (it's plain XUL/JavaScript), but it
would be working much better in native code.

I still think i-search should be started only by a CTRL+ or so combination in
such a way, that it can be implemented into HTML and news/mail composer, too. So
that you can start such a search _all over_ Mozilla's comoponents in the same way.

    
    

    
  
Pretty much everything in mozilla is a component, that's how we do things in
Mozilla...

    
    

    
  
What tgos means is that Typeaheadfind has its own checkbox during install. It
should really just be part of browser.xpi, instead of it's own xpi. That's going
to get fixed, see bug 166712. It was good that way at first because we're moving
forward cautiously. 

It still does need to be a separate .dll/.so component because some embeddors
might not want it.

Tgos, if you have more problems just email me separately instead of venting your
frustration here. We'll file more bugs if necessary.

    
    

    
  
Why does Type Ahead Find have to beep when no links are found? This is really
annoying, especcialy when you are surfing while listenoing to music, in a
library,  in clas etc... There should at least be some way to turn the beeping off.

Thanks.

    
    

    
  
The system poing really is annoying isn't it? For now you might consider
changing it to something more pleasant.

Thanks for the feedback, we're going to take a look at what prefs we want to
expose. If you want to file a bug to add a setting for this that would be great.

    
    

    
  
> For now you might consider changing it to something more pleasant.

This is _really_ not an option in a public environment such as a library. The
machines tend to be locked down, you know.  ;)  Such installations will
definitely want to configure this sound off in Mozilla...

    
  
Depends on: 168408

    
  
Depends on: 168634

    
  
No longer blocks: 168281, 168286, 168289
Depends on: 168281, 168286, 168289

    
    

    
  
I'm having lots of trouble with Ctrl+G (and Ctrl+Shift+G) auto-wrapping - unless
I keep my eye on the scrollbar I don't know it's happened, and I've been known
to search through a document several times before I've realised I've done so.

Can we implement wrapping similar to emacs - first attempt fails with a beep,
pressing Ctrl(+Shift)+G again will wrap to top (bottom)?

Computers in quiet places should be configured at an OS/hardware level to never
make a sound (why should they have sound cards/speakers?) so please keep the
beep on error!

    
  
Depends on: 168824

    
  
Depends on: 169169

    
    

    
  
Note: Mac build files have been checked in as per bug 165632. Mac build 
help appears to no longer be required. "To Be Done" on 
http://www.mozilla.org/projects/ui/accessibility/typeaheadfind.html should 
be modified to state that this has already been done, so no one else 
wastes their time providing this redundant assistance (as I just did...)

    
  
Depends on: 169489

    
  
Depends on: 169490

    
    

    
  
Maybe allow "pop out" of a form field focus with a keystroke; this would be nice
on pages such as Google where JavaScript is used to set the focus to a text
field upon page load. Maybe the user could press the Escape key to remove the
focus from the form field, then the user could do type-ahead find.

    
    

    
  
> Maybe allow "pop out" of a form field focus with a keystroke; this would be nice
> on pages such as Google where JavaScript is used to set the focus to a text

Interesting idea. I know Opera has a similar key because of all their single
keystroke commands (maybe it's f8, I can'r recall).

Anyway, I don't think it's so useful, because you can just press Tab to get to
the next non-text field/combo box. Usually would take more than 1 tab.


    
  
Depends on: 169821
Depends on: 169827

    
    

    
  
It would be nice to have a way to toggle between frames.  i.e. Javadoc and other
online documentation.

Regards,
Raymond Doran

    
    

    
  
I am having problems with Ctrl-G on a particular page. This is pretty much the
only page I do typeaheadfind searches on so I am not sure how widespread the
problem is. The page is:
http://www.mtgnews.com/tracing/on/ (note: it redirects to a different page, but
that one has a numeric url so I didn't want to post it here).

I search for "words of". When I use regular find, I find the 6 occurrences very
nicely. When I use typeaheadfind, I find the first one just fine, but then as I
hit Ctrl-G, the next occurrence flashes on the screen and then the page rewinds
to the top of the section it is in. The only time that doesn't happen is for the
only section in which the text occurs twice.

Is this the right place to enter comments like this? Can anyone confirm? I
downloaded the latest nightly (2002092408) and it is still happening with it.

    
    

    
  
The right place to enter bug reports for type ahead find is to create new bugs,
under the "Keyboard navigation" component, with bug 30088 as a blocker and the
name typeaheadfind somewhere in the title.

Leo, I tried that page you mentioned as a test case. First, it's important to
say this bug appears only in "text only" mode. Second, I did experience this
problem when searching for just "words" in regular find, with wrap around =
true. It does seem to be something specific to the page. Please file a bug so
someone can investigate it more. Thanks!



    
    

    
  
Spam: Adding Type Ahead bugs that did not include this bug as a blocker.
Depends on: 164928, 166574, 167786, 168406, 168862

    
  
Depends on: 170820

    
    

    
  
Here's a suggestion:

How about a pattern that would go to the next form element.

This would really make Moz completely mouseless-browsable, IMHO.

Say you're navigating with type-ahead and then you get to a page that's CGI
generated and the author has say three SUBMIT buttons with names 'aardvark',
'juniper', 'zebra'.  It would be nice to toggle into a 'form element mode' and
then i could type 'zebra' and be popped to that button, hit enter and sumbit
that value.

Moz would be fast unsurpassed chillin and killin at that point.

steven

    
  
Depends on: 170837

    
    

    
  
sgharms: that's already the way it work, at least for me on linux.  The caret
doesn't show up when I tab to the first form element, but there's another bug on
that (I think there's a patch about to go in).
Depends on: 171079

    
  
Depends on: 170921

    
  
No longer depends on: 170921

    
  
Depends on: 171237

    
  
Depends on: 171164

    
  
Depends on: 171260

    
  
Depends on: 172829

    
  
Depends on: 172560

    
    

    
  
this feature just makes me want to use mozilla like vim and less.
comment 93, 95-6, and comment 121 all discuss some of vim's features.
i would like to see even more...

like the aforementioned highlighting all hits,
g for top (home), G for bottom (end),
/ for search, ? for reverse search, (something else for links search?)
n for next hit (ctrl+g), N for previous hit (shift+ctrl+g),
h=left, j=down, k=up, l=right
and all the other applicable ones that i have yet to learn

...this could even be taken to an extreme: textboxes with full vim support
but full textbox vim support should be its own enhancement req bug and further
down the road.

    
    

    
  
n for next hit (ctrl+g), N for previous hit

Wouldn't this conflict with adding an "n" to your search?

    
    

    
  
> Wouldn't this conflict with adding an "n" to your search?

yes under the current system.
i think we should have something more like vim/less:
search starts when you press "/" (typeahead working as it currently does)
and you (optionally) end it with enter.

as it currently stands, i cannot start a new search 
without waiting 3 seconds for the current search to time out.

if i want to search for "vim" i will type "/vim<enter>"
and then i would use "n" and "N" to jump between hits.

this means we would need to invent a search starter for 'search links only.'
on that note, the Find dialog needs a checkbox for 'search links only' to match
this feature.

    
    

    
  
The typeaheadfind docs are here: 
http://www.mozilla.org/projects/ui/accessibility/typeaheadfind.html

"To cancel a find, change focus or scroll, press Escape, or wait for the timeout"

    
    

    
  
> on that note, the Find dialog needs a checkbox for 'search links only' to match
> this feature.

No, it doesn't.

    
    

    
  
>this means we would need to invent a search starter for 'search links only.'
We already have one. If the prefs are set to search all text, pressing ' will 
search for links.

>>on that note, the Find dialog needs a checkbox for 'search links only' to 
match
>>this feature.
>No, it doesn't.

All Type Ahead settings are handled in prefs.js. From what I have deduced, Type 
Ahead and the normal find systems are designed to be as seperate as possible.

    
  
Depends on: 173973

    
  
Depends on: 174040

    
  
Depends on: 174145

    
  
Summary: [RFE] Incremental find (like Emacs isearch) (type ahead find) → Incremental find (like Emacs isearch) (type ahead find)

    
  
Depends on: 175046

    
  
Depends on: 175321

    
  
Depends on: 175162

    
  
Depends on: 175807

    
    

    
  
A couple of things:

1.  It's very easy to accidentally start an incremental search.

This can be annoying, especially if you're half way through a long page &
unintentionally jump to another part of the document.  I think it is likely to
confuse users who don't know about this feature.

Maybe the search should only be started by ' or /, not by an arbitrary
key-press.  This would make it harder to initiate by accident, but still leave
the feature easy to access.

2.  In emacs, I can do the following:

+ after an isearch, go back to where I was before the search (C-x C-x in emacs).

+ during an isearch, cancel the search and go back to where I was in the page
before the search (C-g in emacs).

This is useful if you are reading somewhere in the middle of a long document,
but wish to temporarily refer to another part of the document (use isearch), and
then return to where you left of reading.

3.  isearch-backwards would be nice.  Maybe ? (Shift+/) and " (Shift+') could
initiate these?


    
    

    
  
3.  isearch-backwards would be nice.  Maybe ? (Shift+/) and " (Shift+') could
initiate these?

When I typed up the docs, I have heard that it works like this. First, a visible
match is searched for, then one below the position, and one above. See bug
#170561 comment #25 for more.

    
  
Depends on: 175944

    
    

    
  
First of all:  Wow!  I've been using typeahead find since it's first 
inception, and I love it.   I can't count the times that I've been stuck in 
front of internet explorer, start typing, then scratch my head as to why it's 
not working.   For me anyway, typeahead find is how I browse, having to use 
the rodent really annoys me now.
That said, I think there is still plenty of room for improvement.

I've seen a few comments on reverse search..   I really like this feature in 
emacs, and see no reason that it can't be implemented here.   Right now ctrl-g 
does a find-next..  I think it would be really cool if ctrl-shift-g did a find-
next-backwards.

The second feature that I would really like to see is the ability to use 
typeahead find to select buttons.  If that happened, there would be almost no 
reason left to use the mouse.  Perhaps another prefix character like '.' 
or ';' would mean select only input items.   Or perhaps a new paradigm should 
be used for input controls.  Consider this:

I load a page with a bunch of text, but the reason that I'm on this page is 
that there is a form I need to fill out somewhere (like a logon form, or a 
search box).  In the old off-line world, filling out forms was easy, you just 
hit tab and or shift-tab to jump between elements of a form.  You can still do 
this today, but all to often, you need to get to the form first, and this 
requires the mouse, as the tab key will cycle through far too many links and 
other widgets first.  So here are a couple of ideas:

- Assign a key to find the next input element on the bage, and one to go back 
to the last input element on the page.  Similar to tab and shift-tab in the 
off line world.

- Assume that once the cursor is within a form, that tab and shift-tab will be 
sufficient to navigate around the form.  Therefore some key to jump to the 
first input element of the first form would be really helpfull.  Hitting the 
key again will skip to first input element of the next form, etc...


Just some ideas..  Keep up the great work, you all have revolutionized the way 
(and especially the speed) that I browse the web.  Thank you all!
 




    
    

    
  
geoffrey (re comment 246):
bug 158757 already deals with searching button text (perhaps we could expand it
to include other form parts, like selects?)
backwards search already exists, see the docs:
http://mozilla.org/projects/ui/accessibility/typeaheadfind.html
a quote: "Press Accel+Shift+G or Shift+F3 to find previous, with the current
string you've typed."
the others are suggesting ways to do the _initial_ search backwards (and reverse
which way 'previous' and 'next' point), not a repeat search.

    
    

    
  
[The release notes said I should post RFEs here.  Someone might have already 
mentioned this; I don't want to read through all 247 previous entries...]

I think it is a *big* mistake to start the links search by default whenever any
key is typed.  There ought to be a specific search command key that you have to
type first.  Like / to find any text or ' to find link text.  That is, you
should be requied to type one of these characters to initiate a search.

The reason is that starting a search by default takes away all other single-key
keyboard command possibilities.  type-ahead find is a very cool feature, but it
is not the only cool feature that could benefit from this kind of direct access
to the keyboard.  For example, I'd really love to be able to type g (for 'go')
and then just type in a URL, without having to transfer focus to the location
bar.  And I'd like to be able to bind s (for Search) to do a google search on
whatever text I type after it.

The type ahead find mechanism has so much other potential!  Even emacs isearch
requires you to type Ctrl-S to initiate the search.  Don't mess things up by
starting the searches by default.  Please!

    David Flanagan


    
    

    
  
I absolutely agree with David Flanagan's comment #248.  Type ahead find is a
great feature, but I causes problems to no end with Ctrl-L focusing the address
bar.  OFTEN I will use Ctrl-L to goto an address, but type ahead find is
stealing keystrokes to search the page.  I used to be able to work around this
by pressing Ctrl-Tab when this happened, but the super lame "Ctrl-Tab switches
tabs" ruined that.

I'd much prefer an option to REQUIRE either / or ' be pressed before type ahead
find would be activated.

Hope this makes sense.

    
    

    
  
I'm considering that perhaps typeaheadfind should require a keystroke to start it.

However, I don't understand how it could interfere with Accel+L to focus the
location bar -- it shouldnt' affect that at all.

    
    

    
  
Filed RFE bug 176296 for adding perf to Type Ahead.

Depends on: 176296

    
    

    
  
i also think isearching should require an initiating keystroke.

typeaheadfind is a really useful feature, but as mentioned in the last few
comments, using it for ALL keystrokes limits future keyboard-based enhancements.
i refer you to my comment 238, which argues for shortcuts similar to those of
less, man pages, and vim:
/ for search, ' for search links, 
? for reverse-search, " for reverse-search links,
n for find next, N for find previous,
f for page down, b for page up, g for top, G for bottom, 
j for down one line, k for up one line, h for left, l for right

and maybe comma and period to switch focus between entry boxes (text, select,
check/radio)
(i want the link cycle to differ from the entry cycle, but this will break the
html standards,
http://www.w3.org/TR/html401/interact/forms.html#tabbing-navigation )

    
    

    
  
In response to comment 250, I think that issue might be more with a 'recently'
(during the last two months or so) introduced slowness with the location bar
picking up input. I personally don't see it with ctrl-l, but if I do ctrl-t and
start typing immediately, the first few characters won't show up in the location
bar, but instead will do a type ahead find on the previous page. (I'm sure
there's a seperate bug on this out there, but have been too lazy so far to query
for it.)
Having said that, I'd still be in favor of a required character to start the
search. (I hardly ever search links anyway - only text.) The suggestions in
comment 252 sound good to me, though I don't know we'd need all of them.

    
  
Depends on: 176602

    
    

    
  
I just filed bug 176602, to make the typeheadfind beep less annoying. Seeking
feedback in the bug.

    
  
Depends on: 176605

    
  
Depends on: 176747

    
  
Depends on: 176037

    
    

    
  
I'm having trouble with the backspace key to edit my search pattern -- I keep
backspacing too much and then blinking in surprise as the page changes to the
previous one. This seems like an uncomfortable overloading....

Bug #177005
Depends on: 177005

    
  
Depends on: 177166

    
  
Depends on: 177242

    
    

    
  
How about Accel+f starting typeahead search & Accel+Shift+f opening the find dialog?

After Accel+f, one can start all-text-search with /, only-links-search with ',
one of which could be made default (there must be a pref).

The find dialog can have a checkbox for incremental search [ & of course regexp,
etc. :-) down the line ] in Mozilla 1.3+ at least.

I chose Accel-f for typeahead as less keys pressed must imply less changes in
the view (no dialog boxes). Probably we can switch the two or have a pref for
switching the two. And of course for Aaron's sake have a pref for not requiring
to type Accel-(shift-)?f for typeahead [Everyone else seems to like a key for
starting typeahead].

BTW there are many features users aren't exposed to. I just read what ctrl-l is
supposed to do [comment 249]

    
  
Depends on: 172283

    
    

    
  
I have nothing against an accel+key combination to start an incsearch, but I 
think that pressing Accel + f and then pressing '/' just to start a text serach 
is a bit excesive.

    
    

    
  
Padmanabhan - see what i posted in bug 169489 comment 10;
we could have these options in the preferences:
  (*) require manual initiation of isearches
  ( ) default isearch in links mode
  ( ) default isearch in text mode
  [ ] ctrl + [ ] alt + __  isearch (leave blank for always on), then...
      __ begin isearch of links      __ begin reversed isearch of links
      __ begin isearch of all text   __ begin reversed isearch of text
      note: above entries are CASE SENSITIVE


    
    

    
  
Personally, I dislike any Accel+ combinations. Type Ahead, the way I see it, is
search simplified. You press one button (at *most*), and type what you look for.
It finds it. Or it dosen't. I don't want to have to hit Accel+F, ', and then
type "Owen" to find my name linked on this page. At *most*, I want to type "'Owen".

Now, I would accept it a bit more if the Accel+F spawned a dialog box that I
type my query in. Oh wait... it's called normal find....

Remember that Type Ahead was created for reasons of accessibility. It was also
made to be convienent and simple. It shouldn't be cluttered up by Accel keystrokes.

Also remember that we can't have UI's for *everything*. A Type Ahead find UI
defeats the purpose.

My $0.02 : Give us a pref that allows us to force the start of Type Ahead (using
either / for fulltext, or ' for links), a la bug 176296. Make keystrokes
required by default. Document this feature well. And let that be the end of it ;)

    
    

    
  
All it needs now is an option to switch it off in preferences....

    
  
Depends on: 178305

    
  
Depends on: 177493

    
    

    
  
Hi. I must say I really like this cute feature. I was hoping to suggest one more
thing. When a person is browsing thru a big page, such as this page itself
(http://bugzilla.mozilla.org/show_bug.cgi?id=30088), and he/she is reading the
middle of the document, say after 5 page downs - if the person likes to visit a
particular hyperlink then it would be wise to use type ahead only for the part
of the document which is currently visible. 

I am not sure how much of this I have been to explain properly but let me try
and give you an example. Say your current window shows the 

    -- Additional Comment #78 From Ian 'Hixie' Hickson  2002-07-15 07:32 -

on the top of the window (you are on the 25th page of this document
http://bugzilla.mozilla.org/show_bug.cgi?id=30088) and you want to visit the
link named bug 105565. So you type 105565. Now according to the current
behaviour as soon as I type 1 the browser takes me to the top of the page. The
same thing happens when I type 'bug...'. A bit annoying. Is there a way to tell
mozilla to search for the current set of visible links only. Ofcourse! this
behaviour will be nice only when linksonly is turned on.

    
    

    
  
Navin,

Typeaheadfind is supposed to prefer a visible match on the current page, and
only go back to the top to search the whole page if it couldn't find something
visible. If you're experiencing something different, file a new bug with a
reproducable test case. Mark it dependent on this bug (30088) and use the
Keyboard Navigation component.

    
    

    
  
Apologies if this has been aired already ...

When people do a 'type ahead find' for a single letter, say, and the thing
identifies a link from this: it works really neatly if the page happens to have
an a to z listing at its top - you can quickly step through the a to z pages:

http://www.bathspa.ac.uk/markhelp/alpha/alphad.html

It does depend on actually following the link though - a second 'type ahead
find' for a fresh letter on the same page restarts searching the page from the
'position' of the previous successful 'find'. Would it be better if all type
ahead finds started from the top of the page perhaps?

Just a thought.
Depends on: 179218

    
    

    
  
I still think we need one more improvement to Typeahead find to make it the
mouse-killer that it has started to become.

We need a way to navigate directly to forms on a page.  Typeahead find has no
way of jumping directly to buttons or text fields.

Currently you can hit / to search within the text of a page, or
' to search only links.

I propose that [ would navigate to the first input field of the first form on
the page, hiting it again would navigate to the first input field of the second
form on the page, etc..  Once focus is within a form, tab and shift-tab work
find for navigation.

Either ']' or Shift-'[' ('{') would work well for navigating to the last form on
the page.

The typeahead scoping rules would work great here, first look at the visible
page, then below, then above.

Once again, I love Typeahead find, it has revolutionized my browsing experience.
:)  Thank you.

    
    

    
  
Just checked in bug 177602 -- the sound should be much less annoying now.
Sound is turned off by default in Linux for now, because it needs more testing
and work there:
 bug 179138 - nsSound::Play doesn't doesn't work in Linux
 bug 110385 - sound should be asynchronous in Linux).

Here's the pref to turn sound on:
user_pref("accessibility.typeaheadfind.enablesound", true);
or to turn it off:
user_pref("accessibility.typeaheadfind.enablesound", false);

The next steps will probably be to add a pref for requiring a prefix character
to start typeaheadfind, and then to expose all the important prefs.

    
    

    
  
But it does still beep, instead of doing nothing at all, I hope?

    
    

    
  
Now that this issue is basically complete, I would like to refer people to an
even more key issue which I see is somewhat addressed by bug 95748.  This is the
context of the found bookmarks.  People often need to know where in their
bookmark folder structure that the found bookmark resides, so that their future
use of the bookmark will be faster than conducting a search.  These floating
bookmarks make me dizzy!  Maybe it's old age, but I sometimes forget where I've
placed bookmarks.
  I have looked around, but that bug 95748 is currently the one I see is trying
to address this issue, but is getting little attention.  It is of key importance
to have a search feature that does the basic function that Netscape 4 could do.
 Since there are so many people following this bug, I thought I'd take advantage
of the momentum on bookmarks right now.

    
    

    
  
Hi Aaron (and others)

Please refer to my comment #261 and your reply on comment 262. I agree now that
the typeahead find works for links which are currently visible on the browser's
view - I had to tweak my prefs a bit. My prefs are listed below

user_pref ("accessibility.typeaheadfind", true);
user_pref("accessibility.typeaheadfind.linksonly", true);
user_pref("accessibility.typeaheadfind.startlinksonly", true);
user_pref("accessibility.typeaheadfind.timeout", 3000);


Now, there is a minor enhancement which will make this set real good. Please
consider this...

You are on slashdot.org and on the third page. You like a link and navigate to
it using typeahead or the mouse. You open the link in a new window (via
control+enter or middle click). Notice that the link has the focus for the
keyboard navigation. So if I press tab I will be taken to the next link. Do not
change the focus of the page - I mean do not change tabs yet.

Ok, now you press page-down twice to come to the fifth page of slashdot.org. Try
and press a key for a link on that page. According to the current behaviour the
link finding code will search *after* the current focused link. So, chances are,
that you will end up in some other link - rather than the link you wanted to go to.

Consider a different situation. You visit a link (open a link in the background)
on the fifth page and press page-up to come to the second page. you like another
link and try to navigate to it. But now the search is carried on from down below
to the end of the page and then wrapped to the top bec' the focus was on a link
on the fifth page.

Do avoid this I have to loose the focus on the link somehow. I press escape to
'unhighlight the find' and to loose focus from the link I switch tabs back and
forth. The second way for me to loose focus on the link is to mouse-click on the
page, i.e. click on a unclickable area.

So I would like to suggest a feature and a *pref* for it - say 

user_pref("accessibility.typeaheadfind.linkFocusTimeout", 3000); 
user_pref("accessibility.typeaheadfind.linkFocusTimeoutEnabled", true); 

or something like that - which would help in loosing focus on the link so that
the next find can occur from the current browser view. And if some people do not
like it they can always turn off the 'blur' action.

-Thanks. Navin.



    
  
Blocks: 180656
No longer blocks: 180656
Depends on: 180656

    
  
No longer depends on: 180656

    
  
Depends on: 180977

    
    

    
  
Thanks for bringing incremental search to Mozilla. I use it all the
time in Emacs so I'm very excited about this!

But would it be possible to change the keybindings, so that they match
those of Emacs? I've never saved a webpage, so I don't want to have
Ctrl-s reserved for that - I would rather have it activate isearch
like in Emacs. Is this possible in Mozilla?

    
    

    
  
typeaheadfind does not appear to work on either of the OS9.2.2 macs on my
desk... one never had Mozilla installed, the other usually has the latest stable
version, neither of them have typeaheadfind functionality. Prefs are set to
default (true) and Mozilla 1.2release has been re-installed a few times to no
avail. BTW typeaheadfind didn't work on this mac under 1.2beta either - although
I did get some green highlighting on the test page ONCE. I know how to work it,
I use it on my Win32 version at home all the time... the installer only put in a
.shlb file for typeaheadfind, should there be more files (a .xpt?) as alluded to
in the manual uninstall method ("find all files in your installation
subdirectories that match *typeaheadfind*, and delete those files")?

    
    

    
  
MacOS9.0.4 Moz1.2 milestone release, typeahead doesn't work here either. Doesn't
work with an existing profile,  or with a new profile. Didn't try throwing
everything out yet.

    
    

    
  
This feature is great, but obviously falls down on image menubars. I think
better functionality would be if it also scanned the alt_text for images which
are also links.

Thanks,

-Tennessee
tennessee@today.com.au

    
  
Depends on: 182513

    
    

    
  
It would be nice to prefer links that have the "rel" attributes.
I'm thinking especially about GNU documentation generated
from texinfo source using makeinfo --html.  For an example,
see http://www.gnu.org/software/kawa/Features.html.  The
GNU info program and emacs info mmode allows you to get to the
next page in the logical document sequence using an 'n' key,
the previous page in the document using the 'p' key, and the
"outer" page in the document hierarchy using the 'u' key.
This of course conflicts with type-ahead find, but it would
be nice to define a short (one or two key-stroke) command
sequence that is consistent.  (I.e. the same command should
work on *all* pages that have a rel="next" link, though I
don't care if there is ambiguity with pages that have some
short one-character link text.)

    
    

    
  
per@bothner.com, I think those link features would be bug 102992 and bug 102909
(bug 141989), pretty much.

    
    

    
  
I'm comming a little late to this party - but hey Typeahead find really rocks.

For the record I'm using Phoenix 0.4 so some of this may not apply.

The Shift+Ctrl+G does not seem to step back through the document as I would have
expected.

Could we make the frame focus follow the mouse cursor location? Kinda like it
does for the scroll wheel? This would make it quicker to search in a framed
document.

Keep up the good work.

    
    

    
  
Navin makes a good point about focused link location.

I would like to have a key I can press that focuses the text directly under the
mouse cursor (or if that is off mozilla focuses the text in the middle of the
screen).

This way we can ensure that the searching starts from the point we expected it
to without to much difficulty.

    
    

    
  
Typeaheadfind now working on this mac under Mozilla 1.2.1 - however it wasn't
working on 1.2.1 yesterday... weird and transitory but I'm just happy to have it
working now.

    
    

    
  
hey, mb a bad Q, but i cannot determine how to open links in a new tab using
TAF... sry if this is answered somewhere, but i've searched the site and this
'bug' and haven't yet figured it out/found it....

someone on this page suggested "ctrl-shift-enter" [ comment #80 ], but that just
gets me a new window....  my semi-methodical/semi-random-button-mashing has yet
to succeed either...  can it be done?  i luv tabs... i would luv TAF w/ tabs... :)

tx IA...

    
  
Depends on: 183998

    
    

    
  
CTRL Enter works for me (1.2.1) - opens the type ahead find link in a new tab. I
have the 'Ctrl enter in URL bar opens links in new tab' set in the tabs pref
panel, so perhaps that is required?

    
  
Depends on: 181783

    
  
Depends on: 184518
No longer depends on: 181783
Depends on: 182451
No longer depends on: 172829

    
    

    
  
A very desirable feature would search restricted to the currently focused frame.
Comment #232 also states this. I too encountered this need on a javadoc page.
No longer depends on: 175807

    
    

    
  
in ref to: Comment #279

i checked the check-box, closed MO, killed the quicklaunch daemon, restarted MO,
and ctrl-enter still gives me a new window w/ TAF... i am using 1.2.1 on
win2k... perhaps relevant, i have Mouse Gestures installed....

anyone else experience a similar problem?  my poor tabs :(
Depends on: 185824

    
  
Depends on: 185905

    
  
Depends on: 185907
No longer depends on: 185907

    
  
Depends on: 173606

    
    

    
  
Typeahead Find doesn't seem to behave nicely on the Sun Java API pages (the
frames-based pages).  See http://java.sun.com/j2se/1.4/docs/api/.  There seem to
be a couple of problems.  First, the sheer size of the page makes typeahead find
slow at times.  This is understandable, since it is searching the whole page
(or, rather, nslFind is).  However, the other, big problem that urks me is that,
if I start typing a string, say "StackTraceElement", typeahead find will start
searching for "St", then restart with "a" then "c" then maybe "ktr"... you seem
what I mean.  For some reason, the find doesn't realize that I want all those
characters to be part of a single search.  Is this a known bug, or is there just
a pref I need to adjust to fix this?

    
    

    
  
Brett, the problems with the javadoc pages is filed as bug 185824.

    
  
Component: XP Apps → Keyboard: Find as you Type

    
    

    
  
I need to support comments 250 and 252, etc.  It should at least be /possible/
to require a keystroke to initiate any kind of typeahead.  Otherwise, vi-style
navigation becomes impossible.

    
    

    
  
Ricardo, you will get that when the patches for bug 169489 and bug 176296 get
reviewed and checked in. I expect that to happen before the end of the month.

    
    

    
  
Spam: This bug has been fixed. As we have a new Find As You Type component, a
meta bug is no longer needed. All of the documentation we have to this point
refers to the component, and not the meta bug. I am resolving this bug as FIXED.
Any future issues should be filed as seperate bugs.

See bug #190872 and Find As You Type documentation for new guidelines for filing
new Find As You Type bugs.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
    

    
  
and *zap*
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: