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.

Find on Page -> XP Apps

spam: moving qa contact on some bugs from paulmac to sairuh@netscape.com

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy

nav triage team: I *LOVE* isearch under emacs, unfortunately, don't think we'll get to this. Marking 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.

*** 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

oh, perhaps this should go to 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".

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).

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

Added an attribute to specify iSearch mode

Simply sets the region to search from the beginning of the selection if in isearch mode.

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.

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.

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.

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...

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.

Could someone get this building on mac and check in code warrior project files? It should not yet be part of the default build.

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.

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...

> 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.

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)...

jst: see comment 78.

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

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

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.

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 :)

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=.

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.

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?

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.

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.

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.

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

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.

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.

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.

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

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].

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.

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...

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

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.

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

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.

> 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.