250309 - allow disabling of Find Toolbar with Find As You Type (Find-Toolbar-less FAYT implementation)

Status: VERIFIED WONTFIX

(Toolkit :: Find Toolbar, enhancement)

Description

[sairuh (rarely reading bugmail)]

had discussed this scenario when Blake showed me and Asa the Find Toolbar:

when I use Find As You Type I usually don't need to use the Find Toolbar, so
it'd be nice if there were a pref to prevent the FT from appearing (back end is
fine if there isn't time for a UI).

the main is reason is that I'd be focusing on the content area and looking the
found items there when using Find As You Type. it's rather distracting to see
the FT appear and disappear when using FAYT.

still, the FT looks good, and I wouldn't want to prevent the FT from appearing
if I explictly did an Accel+F (or selected Edit > Find in This Page from the
menubar).

how difficult would this be to implement?

Comment 1

[Lorenzo Colitti]

I second this 100%. The major usefulness of find-as-you-type was that you could
type, find a link, press enter to load the link, find a new link in the new
page, and so on. It was a massive time-saver!

Now to do this you have to press ', type, and then either delete what's in the
find toolbar (by keeping backspace pressed, using the mouse, or some
time-consuming combination like ctrl-a then backspace), or close and reopen the
find toolbar with esc and then '. A big waste of time.

What can we do? I can write a patch, but unless we convince Blake or another
firefox dev it will never be checked in... :(

Comment 2

[alanjstr]

I hate that it makes my screen jump around.

Comment 3

[Mailer Key]

this is even worse than regular popups, totally irritating

Comment 4

[junk]

God, why ruin what's perfect? The prior fayt setup (with the option for links
only unchecked, as it should be by default) is absolutely brilliant in ease of
use and the major benefit of ff beside tabs, imo. How much easier can it be to
explain to a newbie than "start typing"? Now it is complicated for them: "I have
to hit what again, for what? A quote? which one? For what again?" And then an
annoying toolbar pops up? Please reconsider!

The ctr-f is only annoying in that it won't start with your selected text. (Why
not?) But the highlighting is nice and could be included in it. If a toolbar is
insisted upon - bad idea imo - then let it ONLY replace the ctr-f function.

Comment 5

[Steffen Wilberg]

Find as you type works again after Blake's checkins between 2004-07-09 18:11 and
2004-07-09 18:41. You have to enable it at Tools -> Options -> Advanced ->
Accessibility.
It automatically shows the find bar. Is that a problem?

Comment 6

[Steffen Wilberg]

The find bar is automatically removed as well after the FAYT timeout (5 seconds
by default).

Comment 7

[Michael Hendy (Hendikins)]

As somebody who had a reaction of "how do I turn that thing off" before "hey,
typeaheadfind doesn't work!", I'd love to see a way to have this turned off.

I for one find it quite distracting.

Comment 8

[Prognathous]

(In reply to comment #5)
> It automatically shows the find bar. Is that a problem?

I like the concept of the Find Toolbar a lot, but there are quite a few serious
problems with its current implementation:

- ' and / are difficult and inconsistent to use, as they are mapped to different
keys in different keyboard layouts. One moment they work, the next moment they
don't - until one realizes he/she is using another keyboard layout.

- Not being able to use Find-As-You-Type directly is very annoying. We are now
down to Opera's clunky implementation that requires a preceding keypress. Even
IE5/Mac had more direct FAYT that this.

- The fact that the page "jumps" when the toolbar appears is somewhat acceptable
instead of the modal dialog it replaces, but it not acceptable when FAYT is
used. After all, FAYT used to be the most unintrusive way of searching, not anymore.

- Ctrl+F should toggle the Find Toolbar on/off (just like Ctrl+H and Ctrl+B do
with History and Bookmarks)

Prog.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040709
Firefox/0.9.0+

Comment 9

[Legenda]

I too would like to see FAYT back as it was - or at least an option to re-enable
the old functionality. IMO this new find toolbar **** is completely idiotic.
Sorry, but I'm just so damn irritated having to hit that ' key every time :(

Comment 10

[Asa Dotzler [:asa]]

(Nearly) all of you, this is not an advocacy forum nor is it a complaints
department. If you continue to spam bugzilla with comments unrelated to the
technical issues of bugs, your accounts will be disabled. Take it to
mozillazine.org or the newsgroups, either one, but don't waste developer and QA
time by spamming our bugs. 

Comment 11

[Nitin (vfwlkr)]

forum link:
http://forums.mozillazine.org/viewtopic.php?t=96481

Comment 12

[Ben Goodger (use ben at mozilla dot org for email)]

-> Find Toolbar component.

Comment 13

[Asaf Romano (gone)]

not a mac-specific issue, canceling blcoking1.0mac

Comment 14

[Michael Clackler]

Attachment: patch to fix

This patch adds an advanced Accessibility Option "Disable Find Bar while using
Find As You Type".  When this option is selected, the find bar will remain
hidden when using FAYT and the find string will be displayed on the status bar.
 

The find bar will only be hidden if the options "Use Find As You Type" and
"Disable Find Bar while using Find As You Type" are selected and the find is
inititated with FAYT.  If the option "Use Find As You Type" is selected and
"Disable Find Bar while using Find As You Type" is not, the find bar will open
when using FAYT.  If the option "Disable Find Bar while using Find As You Type"
is selected and "Use Find As You Type" is not, the "Disable.." option is not
used.

If ctrl-F, ', or / are used to initiate a find the find bar will open
regardless of the option settings.

Comment 15

[Asaf Romano (gone)]

it adds a gui, right?

If the answer is "yes" you need r+a in less than 48h.

Comment 16

[Asaf Romano (gone)]

(In reply to comment #14)

Can you also create the same patch without UI (meaning: pref will be set only in
about:conifg)

In addition: I think that when the pref is set, only Accel+F should bring up the
find toobar.

Comment 17

[Michael Clackler]

Attachment: patch v2

This patch responds to comments by Asaf Romano

1. UI for preference is removed.  Preference is now set through
"accessibility.typeaheadfind.disablefindbar" in about:config

2.  If "accessibility.typeaheadfind.disablefindbar" is set to TRUE, the find
bar will not open using FAYT, ', or / to initiate a find. (The find bar will
only open with ctrl-F)

3. If "accessibility.typeaheadfind.disablefindbar" is set to FALSE, the find
bar will open under all circumstances.

Comment 18

[Asa Dotzler [:asa]]

Comment on attachment 155460 [details] [diff] [review]
patch v2

please don't request approval until the patch is sufficiently reviewed. thanks.

Comment 19

[Nitin (vfwlkr)]

I believe this was minussed before it had a patch.

setting status whiteboard [have patch] and setting blocking request.

Comment 20

[chris hofmann]

Comment on attachment 155460 [details] [diff] [review]
patch v2

ben, can you have a look at the patch?

Comment 21

[chris hofmann]

think it is too late to try and add this feature for 1.0.

Comment 22

[Alan Batie]

I will add that accessibility.typeaheadfind.disablefindbar fixed my problem,
which was that the findbar would steal focus when entering text in a form (in my
case, a wiki).

Comment 23

[Prognathous]

(In reply to Chris Hofmann, comment #21)
> think it is too late to try and add this feature for 1.0.

How about 1.5?

Prog.

Comment 24

[Worcester12345]

Hoping this gets fixed quicker than bugzilla bug 258285, as that one is a real
pain, and hoping this would be a workaround.

Comment 25

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

Comment on attachment 155460 [details] [diff] [review]
patch v2

currently, we have moved code of find toolbar to findBar.js. This patch cannot use.

Comment 26

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

I will fix this. Taking this bug.

Comment 27

[Worcester12345]

(In reply to comment #16)
> (In reply to comment #14)
> 
> Can you also create the same patch without UI (meaning: pref will be set only in
> about:conifg)

A toggle or checkbox would have been nice though. Any chance of reconsidering this?

Comment 28

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

Oops, Excuse me, I misread this report.
Does this report mean that we should implement FindToolbarless FAYT?

If so, we cannot implement the feature. Because currently FAYT needs the editor of Find Toolbar. So, we cannot run FAYT without the Toolbar.

Comment 29

[John Lewis]

I would really like to get rid of the search box while still using FAYT.  Please give me a way to do this.

Comment 30

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

I confirmed by the patch (attachment 155460 [details] [diff] [review]).
We cannot implement this feature. Because without editor, we cannot handle IME.
See bug 259454 and bug 270936.
# We cannot process the international text inputting only with JS code.

And we cannot use statusbar for find string. Because the statusbar SHOULD display the URI of found link. See bug 307874.

-> WONTFIX

Comment 31

[John Lewis]

(In reply to comment #30)
> I confirmed by the patch (attachment 155460 [details] [diff] [review] [edit]).
> We cannot implement this feature. Because without editor, we cannot handle IME.
> See bug 259454 and bug 270936.
> # We cannot process the international text inputting only with JS code.
> 
> And we cannot use statusbar for find string. Because the statusbar SHOULD
> display the URI of found link. See bug 307874.
> 
> -> WONTFIX

Can't we simply make it CSS display:none?  I don't mind it being there as long as I don't see it ;-) 

Comment 32

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

We cannot so. If the editor is hidden(by "display: none;" or "visibility: hidden;"), the editor cannot get focus. IME needs focused editor.

If it doesn't so, IME and several language inputting have the "inputting" state.
For ASCII users, it may not be understood. Because ASCII locale inputting doesn't have this state. In this case, there are only the "inputted" state. But in other locale, there is the case that is a character inputted by two or more typing. For this case, we cannot solve the inputted character from key inputtings.

Comment 33

[Mike Connor [:mconnor]]

there's probably a userChrome.css hack that'll do this, but we're not going to break IME for this case.

Comment 34

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

Thank you, Mike.

Comment 35

[Prognathous]

How about offering this feature as an off-by-default option, so that users who don't need IME could enjoy it?

This way, those who use IME will not have any problem (since the current behavior will remain the default), but those of us who dislike Toolbar-FAYT will have an option to hide it.

Prog.

Comment 36

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

If we do so, we need extra variables and extra codes(Maybe the code size is large).
And the code may become spaghetti. Because we need the both code of Fx1.5(current) and Fx1.0(old) in a version. The new findBar.js and old findBar.js are not alike.

The mixed code will make unhappy everyone.

Comment 37

[Prognathous]

(In reply to comment #36)
> The mixed code will make unhappy everyone.

It won't make the 94 people who voted for this bug unhappy, I can assure you that. 

Anyway, you seem to have made up your mind, so I won't spam this bug with any further comments.

Cheers,

Prog.

Comment 38

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

> It won't make the 94 people who voted for this bug unhappy, I can assure you
> that. 

I don't think so, the doubled code structure make to slow down the development. Also, the developers may make regressions easy. These things make unhappy all users (including the voting people).

Please understand psudo-focus mechanism that is used in current FAYT. This is a new feature for international text inputtable. But this mechanism is based on two conditions:
1. the browser content does not have focus.
2. the editor of Find Toolbar has focus.

For solving this problem, we need many, many extra code only for an optional function. This is not clever. If this is a "bug", we must fix this with large patch. But this case is not so. This is "enhancement".

Comment 39

[John Lewis]

(In reply to comment #38)

> For solving this problem, we need many, many extra code only for an optional
> function. This is not clever. If this is a "bug", we must fix this with large
> patch. But this case is not so. This is "enhancement".

I think I speak for the majority of the voters when I say this is a result of a bad "enhancement" that previously didn't exist.  We were using FAYT without a toolbar and were happy doing so.  When the toolbar was added it was a mistake to link it directly to the FAYT functionality.  It has made it annoying to navigate without a mouse and is distracting as a UI element.

The bug, in short, is linking FAYT to the toolbar, when they never needed to be linked.

Comment 40

[David Craig]

To the poster above me: you certainly speak for me. I've been waiting a year and a half, patiently, to get this bug fixed so that I can migrate from mozilla to firefox, and now it looks like I won't be doing that until I absolutely can't view webpages any longer. I appreciate the hard work that all of the developers do on firefox, but FAYT is such a beautiful feature that is completely wrecked by the find bar popping up, and it seems shortsighted to ignore a bug that has been irritating a good number of users for a long time (assuming people who have bothered to find this bug and vote represent a much larger segment of total users.) I'll stop spamming the bug system now, but I wanted to make my voice heard at least once in a year and a half on the only firefox usability issue I've ever actually cared about.

Comment 41

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away 4/27 - 5/6)]

> (In reply to comment #38)
> We were using FAYT without a
> toolbar and were happy doing so.  When the toolbar was added it was a mistake
> to link it directly to the FAYT functionality.

This is wrong. IME didn't work fine. Current FAYT of SeaMonkey has some bugs for IME inputting(fixing these bugs very difficult works). Also, on trunk, I'm working for IME better implementation.(bug 55751) But this work is very difficult by some reasons. In a reason, that is IME handling of FAYT of SeaMonkey is not working fine. I think SeaMonkey should port the FAYT of Firefox. Because for design of UI, implementation of Firefox is best. Because it uses "text" editor for text inputting event handling. The browser content should not handle text input. Because it is not designed so. The old FAYT mechanism is not good design.

> It has made it annoying to
> navigate without a mouse and is distracting as a UI element.
I don't think so, the Find Toolbar returns focus to browser content or found link element when it is closed(by "Esc" key or timeout).

> The bug, in short, is linking FAYT to the toolbar, when they never needed to be
> linked.
Did you read the source code? FAYT isn't linking Find Toolbar.
FAYT *needs* Find Toolbar in current design.
(Find in This Page + FAYT + FindToolbar = one component)

I have a proposal. We have the code of findBar.js in 1.0.x, and we have a patch(attachment 155460 [details] [diff] [review]). We can use these code for extension. If the extension needs default FAYT killing pref, I will create the patch. In this way, we can make both functions and Trunk have no damage(I.e, Firefox developers don't need to manage doubled codes).

Please create new extension. We don't fix this bug *in* Firefox. The reasons are already commented. This bug already VERIFIED for WONTFIX.