Mozilla Firefox: No buttons at Quick Find

[Sascha Morr]

Binary package hint: mozilla-firefox

Hello,

i just install Ubuntu Edgy (6.10) to test it. And one of the first failures i saw was that there a no buttons at Quick Find (Edit » Preferences » Advanced » General » Search for text when i typing) in firefox. Hope this is a bug and not intention.

Find » http://img206.imageshack.us/img206/1818/firefoxbug2gy7.png
Quick Find » http://img224.imageshack.us/img224/7149/firefoxbugcp6.png

cheers
Sascha

[Myk (myk)]

Although ' is a fundamentally different kind of search, / is functionally the same as regular find (i.e. it searches through the exact same text and highlights/focuses matches in the same way), and nothing in regular find makes it less usable than / for accessibility-focused users.

So there's no downside to making / start a regular find instead of a quick find, and there's plenty of upside (f.e. the "Highlight All" option and a clear message when the text isn't found).

It does make sense to continue to differentiate ' from regular find, however.

[Pkasting (pkasting)]

To be very clear after myk's comment, I don't think this bug is proposing that / should start regular find, only that the autostart pref should cause _typing at all_ to start regular find.

Whether this would make Fx2 depends on two things:
* Judgement of reward involved, which depends on our evaluation of who uses the autostart pref and why. If every user in the world just wanted ctrl-f behavior, this is higher reward. If no one did and people really wanted the accessibility case, this is clearly 0 reward. Since even in the first case the cost of getting a find dialog is small (one keyboard shortcut), the maximum reward here is probably not going to be judged very high regardless.
* Judgement of risk, which will depend heavily on how scary the patch for this would be and, if not terribly scary, how fast it could get baking on trunk.

I'm going to nominate for blocking based on the sense that, without this, we have inconvenienced a lot of autostart users (most?) in an avoidable way. But it's very late in the cycle to take such a change.

[Myk (myk)]

(In reply to comment #2)
> To be very clear after myk's comment, I don't think this bug is proposing that
> / should start regular find, only that the autostart pref should cause _typing
> at all_ to start regular find.

For me / and <autostart> both invoke the exact same function (just via a different mechanism), but fair enough, I've filed the separate bug 347261 on making / start regular find.

[Beltzner (beltzner)]

(In reply to comment #1)
> Although ' is a fundamentally different kind of search, / is functionally the
> same as regular find (i.e. it searches through the exact same text and

I'm missing some background. What's the history of the "'" and "/" shortcuts?

[Pkasting (pkasting)]

Created attachment 232030
patch v1

This should do it. This also cleans up the code in that area a bit; a branch version of this patch would be less intrusive.

Over to beltzner for ui-review about whether we want to try this out on trunk.

[Pkasting (pkasting)]

(In reply to comment #4)
> (In reply to comment #1)
> > Although ' is a fundamentally different kind of search, / is functionally the
> > same as regular find (i.e. it searches through the exact same text and
>
> I'm missing some background. What's the history of the "'" and "/" shortcuts?

I assume this discussion is relevant to bug 347261 as this bug doesn't propose changing the presence or meaning of those shortcuts at all. (I don't say this to cut discussion off, just to make sure I understand what beltzner is asking for and why.)

[Moz-jciv (moz-jciv)]

I thought what beltzner was asking was where did this find feature (or at least the choice of / and ') come from in the first place. I presume the / comes from the search feature of Vi, but I don't know where the ' comes from. Possibly because it is a nearby key that isn't used for much.

[Zeniko (zeniko)]

Two reasons NOT to invoke the Find bar:
* Currently FAYT allows to find links and hit Enter to follow the link. This functionality would be broken.
* Currently the UI invoked by FAYT is dismissed automatically after an idle-timeout. This would be broken as well.

FAYT has always worked in the same way as /. Why break that now?

I'd be especially unhappy about such a change because on my keyboard / equals Shift+7 and is thus about as quick as Ctrl+F - so FAYT is the "real" Quick Find.

[Supernova00 (supernova00)]

I believe the reported is actually talking about on pages where you just type and the quick find comes up (like go to any page without a input bar) then type, and quickfind is invoked. To me that is useless, the control+F find function should be launched like it use to.

QuickFind is useless in almost any case.

[Pkasting (pkasting)]

(In reply to comment #8)
> Two reasons NOT to invoke the Find bar:

Yes, clearly whether this is a good idea hinges on whether users who use autostart wanted the current Find behavior or Quick Find behavior. If the majority of users are in the second camp, as it sounds like you are, then this is a bad move. However, at least some users perceived (incorrectly) that FAYT "worked like ctrl-f" (which, since most people didn't know or care about the differences between / and ctrl-f, was the same thing in their minds, though not in reality). Those users are in the former camp. What's the most common use case here?

FWIW, the lack of auto-dismiss on Find used to drive me insane, but now I not only am OK with it, but am slowly coming to consider auto-dismiss to be a usability loss; I certainly can't think of what use cases of mine it actually breaks to not have it. Similarly, the lack of following links with Enter in Find mode doesn't really bother me, because usually if I want that, I explicitly wanted to navigate in such a way, in which case I hit '.

(In reply to comment #9)
> To me that is useless, the control+F find
> function should be launched like it use to.

This is what I was speaking about above; it never did do the same thing as ctrl-f, but people perceive that it did.

[Philringnalda (philringnalda)]

The original history, including the Emacs heritage and the reason it goes away (so you can type [pon] to get to the section on ponies, then automatically get back your space-to-scroll) is in bug 30088.

[Beltzner (beltzner)]

Aaron: I've got some thoughts on this, but I'd like to get your input on how quick find is used as an accessibility feature. Specifically I'm wondering:

 - how do the majority of a11y users invoke find?
 - is the auto-dismiss function needed for a11y users?

[Aaronleventhal (aaronleventhal)]

Catch me on IRC so that I can understand the question better. The truth is probably 95% of users just use Ctrl+F because most folks just use the keystrokes they know, and may not discover anything else.

I will say that those who discover the different features of find are very happy with them. Removing the features for those who type / in the name of making it visually distinct doesn't make sense to me, but I haven't read the entire discussion, so there may be a good reason for it. The other thing is, if we're going to make / visually distinct ("Quick find"), it would be nice to have ' also have a different label ("Quick link find" or "Link find"). That would make that feature more discoverable.

[Pkasting (pkasting)]

(In reply to comment #13)
> I will say that those who discover the different features of find are very
> happy with them. Removing the features for those who type / in the name of
> making it visually distinct doesn't make sense to me,

Bug 347261 suggests making / start Find mode.

> we're going to make / visually distinct ("Quick find"), it would be nice to
> have ' also have a different label ("Quick link find" or "Link find"). That
> would make that feature more discoverable.

Bug 347249 is this suggestion, and I was going to write a patch today to use the phrase "Quick find links", unless beltzner et. al think one of the above patches is better.

[Pkasting (pkasting)]

(In reply to comment #13)
> unless beltzner et. al think one of the above
> patches is better.

s/patches/phrases/

[Myk (myk)]

> Bug 347249 is this suggestion, and I was going to write a patch today to use
> the phrase "Quick find links", unless beltzner et. al think one of the above
> patches is better.

Another possibility is "Find Links". Seems to me that "quick" isn't really the key distinguishing aspect of this feature (' isn't much slower than ctrl-f, and it's certainly not slower than /); the link-specific focus is what differentiates it.

[Hasse-jasajudeju (hasse-jasajudeju)]

Whatever bar you choose to use for FAYT, please make it auto-dismiss. IMHO, the only redeeming feature of having any type of find bar pop up to block part of the content area when I'm keyboard navigating is that it can be safely ignored if the bar will go away all by itself.

[Aaronleventhal (aaronleventhal)]

Is the auto dismiss based on a timer? Sorry to say, but if it is that's bad for many users. Keep in mind that some users type *a lot* slower than you. This includes ordinary keyboard users such as newbies and elderly users, as well as single switch device users (e.g. Hawking) or onscreen keyboard users with a head pointer. Unfortunately, you can't really design a timeout that works for everyone, which is why it's against general accessibility guidelines.

[Philringnalda (philringnalda)]

(In reply to comment #18)
> Is the auto dismiss based on a timer?

That's how someone named Aaron Leventhal did it, yes: see bug 30088 comment 41.

[Aaronleventhal (aaronleventhal)]

(In reply to comment #19)
> (In reply to comment #18)
> > Is the auto dismiss based on a timer?
>
> That's how someone named Aaron Leventhal did it, yes: see bug 30088 comment 41.
>

LOL, that's true -- you busted me. But at least we did have the alternative untimed Ctrl+F back then. Find as you type wasn't the main way to find yet, and most of the users were still using the dialog. Will the timer be used to dismiss the current Ctrl+F find?

[Aaronleventhal (aaronleventhal)]

Also, that timer was configurable via UI-exposed prefs. Where timers exist they have to be configurable.

[Pkasting (pkasting)]

(In reply to comment #17)
> Whatever bar you choose to use for FAYT, please make it auto-dismiss. IMHO, the
> only redeeming feature of having any type of find bar pop up to block part of
> the content area when I'm keyboard navigating is that it can be safely ignored
> if the bar will go away all by itself.

The Quick Find bar does auto-dismiss. And I think the Find bar doesn't play nicely with auto-dismiss; how can you have a bar with mouse-clickable controls that autodismisses? And certainly the whole point of the visual differentiation was to note that the two modes behaved differently, so we couldn't make the Find bar dismiss when invoked one way and not the other, or we'd just be back at the previous release's state, which got bugs filed due to "why did my bar go away/not go away when I wanted" since people didn't realize there were two modes.

So I think either this bug gets WONTFIXed and you have an autodismissing Quick Find bar, or it gets FIXED and you have a non-dismissing Find bar. Note that the find bar doesn't cover the content on the page, it changes the size of the content area, so nothing is "hidden under the find bar". That means that it _should_ be "safe to ignore".

(In reply to comment #20)
> LOL, that's true -- you busted me. But at least we did have the alternative
> untimed Ctrl+F back then.

And still do

> Will the timer be used to
> dismiss the current Ctrl+F find?

No, the Find bar is very intentionally not auto-dismissed. It can be closed via a close box or the escape key.

[Moz-jciv (moz-jciv)]

Simon does make a good argument. Enter to follow the link certainly is an important accessibility feature and the timeout likely is as well.

I know adding prefs is not popular, but many people think two separate find functions is bad. What if we had a pref to control the Find and QuickFind bar behavior. If we can assume that users find one method they like and stick with it, having a visible accessibility pref to control link following (which I think is the important difference) on both QuickFind and Find. A side effect of the behavior was controlled by a pref is the two bars would not need to be visually distinct anymore (other than a link/text indicator as in bug 347249).

Speaking of the visually distinction, has anyone checked with an accessibility expert on whether removing the UI elements is a bad idea? QuickFind is mainly an accessibility feature and if we are thinking of it as mainly a quick search that may be wrong. Currently it is the only way to search links on a page, so loosing the UI could easily affect its target users. They can't just use Ctrl+F instead if they prefer/need the UI.

The timer question Aaron brought up is something I wondered about, for some disabled users not being "trapped" in the bar is surely important. But you certainly would not want them to be in the middle of a search at the time. As it is now, the timeout seems like it would give even very slow typists enough time to finish though as long as they know what they are searching (not looking it up in the middle of the search). A case that might be a problem is hunt and peck with very bad vision. But dismissing the bar relatively quickly is probably too beneficial to others with disabilities to not do it.

[Pkasting (pkasting)]

(In reply to comment #23)
> I know adding prefs is not popular, but many people think two separate find
> functions is bad.

The current state is as close as possible to the original Seamonkey behavior from back in bug 30088. There have always been two separate find functions: Find and FAYT. In the old suite one had a dialog and one sat in the status bar. The current trunk/branch state preserves the functionality of both modes while making the UI of both a bit more exposed. Find has controls and doesn't auto-dismiss, just like back in the Dialog days, while FAYT has no controls and does autodismiss -- just like back in the status bar days.

Even in the Firefox 1.0/1.5 code, there were two separate find functions. It's just that, for convenience in coding, Blake Ross reused the find bar UI for the FAYT UI, which provided it with controls like Find had had. But how much sense to those controls make for the purposes of a FAYT that autodismisses and was always used successfully without controls?

If people really want FAYT then I think the current visual distinction serves them fine. If they really want Find and just need a more convenient way to trigger it, then this patch provides that.

> What if we had a pref to control the Find and QuickFind bar
> behavior.

So, what you propose is nuking the idea of two find modes entirely, and instead having an "autodismiss, and dismiss on blur" pref (as well as a "behavior of the enter key" pref?)? While that's probably closer to my original idea of what I wanted, I'm just not convinced prefs are great. Why can't we just do the right thing?

...In any case this idea is something of a bugmorph... I'm very wary of derailing this bug with 3000 ideas of what Find should be in an ideal world. Let's leave that discussion for a wiki page somewhere and keep this bug about whether or not this particulr change would be a good thing.

[Bamm Gabriana (bamm-gabriana)]

If a person selects "Begin finding when you begin typing", then the Find bar (or whatever bar) should not autodismiss.

Users who check this usually expect to never have to use Ctrl+F anymore. Well, at least those I know of.

[Pkasting (pkasting)]

Created attachment 234493
patch v2

Unbitrotting the earlier patch after I landed some cleanup on trunk.

[Vectorspace (vectorspace)]

(In reply to comment #8)
> * Currently FAYT allows to find links and hit Enter to follow the link. This
> functionality would be broken.

1.5 only had the regular find bar, and still allowed you to hit enter on a link to follow it - why was that lost?

[Pkasting (pkasting)]

(In reply to comment #27)
> (In reply to comment #8)
> > * Currently FAYT allows to find links and hit Enter to follow the link. This
> > functionality would be broken.
>
> 1.5 only had the regular find bar, and still allowed you to hit enter on a link
> to follow it - why was that lost?

No, it didn't. 1.5 had the same two modes we have now; they just LOOKED identical to each other. In "find" mode enter would not follow links. In "quick find"/FAYT mode, it would. This is one of the reasons we made the modes look different: they _were_ different.

[Pkasting (pkasting)]

Continual reading of forums and comments ever since we changed this has led me to believe this bug is the behavior people expect. The text in our pref panel used to say "begin finding", so people assumed they were getting Find.

Nominating to block; I think we should take this for RC1. There shouldn't be any risk (a whitespace-ignoring diff shows that I'm just changing the condition for triggering quick find mode).

[Mjf3232 (mjf3232)]

Quick Find is useless, Find should be invoked

[Mano-mozilla (mano-mozilla)]

You _do_ realize this kills links-only FAYT mode, eh?

[Moz-jciv (moz-jciv)]

This will not kill Link only find. It just makes _auto_ type as you find bring up the Find bar which Link only find has nothing to do with. Link find will still be started by hitting the quote (') key. And regular Quick Find (as it is now) would still be brought up by the slash (/) key (I presume). What this bug is about is the preference that invokes find when a user types anything outside a text box.

I have been reading many of the questions and complaints about auto FAYT in the forums as well. Peter is correct that most using it intended the behavior to be as described in this bug because they thought that is what they were getting in Fx 1.5. The only real way to figure this out is to try it for the next beta and see the reaction. If lots of people complain about the change it could be easily reverted to what we have now.

[Nickolay Ponomarev (asqueella)]

(In reply to comment #29)
> Continual reading of forums and comments ever since we changed this has led me
> to believe this bug is the behavior people expect.

You do realize that there's a significant portion of power (and disabled?) users that use FAYT ever since it was introduced in seamonkey? They don't complain because you didn't break them (yet!) - quick find suits older FAYT users quite well.
Are you sure those users are minority (given that people who turned FAYT on are likely to be power users or disabled users)?

[Pkasting (pkasting)]

(In reply to comment #31)
> You _do_ realize this kills links-only FAYT mode, eh?

See comment 32; this has no effect whatsoever on links-only FAYT.

(In reply to comment #33)
> You do realize that there's a significant portion of power (and disabled?)
> users that use FAYT ever since it was introduced in seamonkey? They don't
> complain because you didn't break them (yet!) - quick find suits older FAYT
> users quite well.
> Are you sure those users are minority (given that people who turned FAYT on are
> likely to be power users or disabled users)?

I've still seen little to no explanation of what it is about Quick Find's differences that make it "not break" power/disabled users while Find _would_ break them. In fact, the auto-timeout seems like a hindrance to disabled users. Also, yes, the historical market share of Seamonkey versus the current market share of Firefox convinces me that Firefox users with FAYT on are likely to have started using the feature in Firefox, where it appeared to be Find, rather than in Seamonkey.

As far as I can tell, the small number of Seamonkey FAYT users who are now using Firefox instead of sticking with Seamonkey would probably still be well-served by this behavior change.

[Mike Connor (mconnor)]

Not going to block on this at this late stage. The entire point of showing different UI for Find and Quick Find is that the behaviours are different, and thus showing the same UI was considered confusing. This might in fact be a WONTFIX, but we can discuss this when there's more time.

[Pkasting (pkasting)]

(In reply to comment #35)
> The entire point of showing
> different UI for Find and Quick Find is that the behaviours are different, and
> thus showing the same UI was considered confusing.

I think you misinterpreted my request. I'm not asking for us to just show the Find UI (which, indeed, would be retarded). I'm asking for autostart to actually trigger the Find _behavior_ (and thus UI), so that Quick Find is only triggered by / or '.

Resetting blocking request (I'm not trying to annoy you, I just want you to know what I actually want).

[Zeniko (zeniko)]

With the risk of repeating myself:

Do you really think that all those people complaining about FAYT no longer being mouse-accessible are aware of the fact that they'll have to dismiss the so-easily invoked Find bar by either hitting [Esc] or "that little X"? At least to me, this seems rather cumbersome.

Additionally, on those keyboards where ' isn't that easily available as on the US English ones, keyboard-navigating to a link would be getting slightly more annoying as well.

I'd rather see Quick/Link Find be made more accessible for international users before toggling the switch in this bug.

[Pkasting (pkasting)]

(In reply to comment #37)
> Do you really think that all those people complaining about FAYT no longer
> being mouse-accessible are aware of the fact that they'll have to dismiss the
> so-easily invoked Find bar by either hitting [Esc] or "that little X"? At least
> to me, this seems rather cumbersome.

Or not dismiss it at all; it works fine if you just leave it there. (In fact, works better, because if you leave it, it doesn't keep changing the vertical size of your content area).

> Additionally, on those keyboards where ' isn't that easily available as on the
> US English ones, keyboard-navigating to a link would be getting slightly more
> annoying as well.

Why? The old autostart behavior started Quick Find text mode, not Quick Find links mode, so it wasn't any easier to get to a link. The _only_ way to get Quick Find links mode has always been to hit ', and this bug doesn't change that.

> I'd rather see Quick/Link Find be made more accessible for international users
> before toggling the switch in this bug.

I don't think they're connected at all.

[Mike Connor (mconnor)]

Oh, that's an even worse behaviour, IMO. That has never been how it worked, so this is a _very_ late behaviour change, and thus an automatic minus.

Changing how autostart works is not RC1 fodder, unless it were to the old behaviour. Now that we clearly understand the bug, this is a WONTFIX.

[Pkasting (pkasting)]

(In reply to comment #39)
> Oh, that's an even worse behaviour, IMO. That has never been how it worked, so
> this is a _very_ late behaviour change, and thus an automatic minus.
>
> Changing how autostart works is not RC1 fodder, unless it were to the old
> behaviour. Now that we clearly understand the bug, this is a WONTFIX.

The whole point is that this change makes us NOT _apparently_ change the behavior. Most users believed (and the UI seemed to reinforce) that autostart started Find mode. Now that we've made it clear it doesn't they're very angry (have you been reading the forums, comments on "B2 released" articles, etc.?). We should make the behavior be what almost everyone has always thought it is, and what almost everyone wants, and consider the fact that it used to not work the way the interface suggested it should to be the bug we fixed with the visual distinction.

This should DEFINITELY not be WONTFIX (for Fx 3 at the very least!), and I don't think it should be auto-minused for RC1 either.

[Nickolay Ponomarev (asqueella)]

> I've still seen little to no explanation of what it is about Quick Find's
> differences that make it "not break" power/disabled users while Find _would_
> break them.

From my experience (I'm a Firefox user for almost 3 years already):
 1. FAYT is easy to invoke way to navigate links ("'" is not as easy to hit).
 2. Regarding auto-dismiss. I agree that auto-dismissing may be a usability problem and annoyance in general. I'd be fine with disabling this behavior if the Find toolbar - which isn't auto-dismissed - didn't have this annoying problem:

If you invoke Find toolbar, search for something, then click inside the page (or make the FT lose focus in any other way), you can no longer dismiss the Find toolbar by hitting Escape - you have to use the mouse or, if you're really smart, focus it with CTRL+F then hit Escape.
You'd think it's a minor issue, but for someone who has set a special option to avoid having to hit CTRL+F to start searching it's pretty annoying to do this every time you search for something. (And I can't just let the find toolbar be open all the time, as I dislike the always-visible bars.)

Yes I can always start searching by hitting '/', but so do FT users (they need to hit CTRL+F instead of '/'). Both the Find Toolbar and QuickFind mode have their pluses and minuses, and it's not clear to me why the change requested in this bug makes our users more happy overall ;-)

[Mano-mozilla (mano-mozilla)]

Enter-on-links is used quite often in this modein this mode, and this breaks that. I'm a bit concerned to see how you're ignoring this repeatedly.

[Mano-mozilla (mano-mozilla)]

argh, s/modein this/

[Nickolay Ponomarev (asqueella)]

So why do people want Find Toolbar appearance for FAYT? There are four functional differences from the point of view of keyboard users:
1. Auto-dismissal
2. Behavior of Enter
3. No way to highlight all from QuickFind (this actually bothers me as a QuickFind user)
4. No way to match case from QuickFind

(Search forward/backward is F3/Shift+F3).

Why can't we disable auto-dismiss (after fixing the problem described in my previous comment), enable CTRL+Enter to highlight all occurrences and leave the current minimal UI? There would be two differences left:
* Enter behavior (I don't suppose this is a deal-breaker)
* Lack of Case sensitive search functionality (almost nobody uses that on a regular basis)

[Pkasting (pkasting)]

(In reply to comment #44)
> (Search forward/backward is F3/Shift+F3).

...which is not known or easy for people who want to use the mouse buttons or alt-n/alt-p like they did previously (which Quick Find won't do).

But I give up. I'm tired of arguing and of trying to make people happy. Someone else can take the flames.

-> WONTFIX.

[Supernova00 (supernova00)]

Mike Connor, please read the comments and especially the forum thread. No one was happy with the change to make FAYT invoke QuickFind. Personally and I'm not alone, see absolutley no point in FAYT invokeing Find...truthfully I don't find "find" useful one bit.

http://forums.mozillazine.org/viewtopic.php?t=456744&start=0

Please read that.

[Supernova00 (supernova00)]

err should have been "truthfully I don't find "quickfind" useful one bit."

Sorry for bugspam, just wanted to make that clear.

[Moz-jciv (moz-jciv)]

I filed this bug originally and until it was brought up again recently had totally given up on it. The main argument against it seemed to be that this change isn't the optimal find solution; we don't know what that solution is; and doing nothing is better than attempting to improve it. As long as we have two separate find features (or three depending on how you count), there is going to be user confusion.

This change has NOTHING to do with Link Find which is the main complaint recently. Auto start of FAYT never entered link find mode. By auto start we mean selecting the preference, "Search for text when I start typing." As in you type the first letter of what you want to find, not ' or /.

Thanks for trying Peter.

[Vectorspace (vectorspace)]

I can see why some distinction between the find modes is necessary, if they act differently with different key controls, with the only distinction being which of the 4 methods you used to call it up. But I don't see the need to reduce the functionality of the other modes by removing buttons.

Is there a reason why the Quick Find Bar can't still contain some or all of the controls from the normal find bar?

If FAYT invoked the standard find bar, the only lost functionality would be the ability to hit enter when you find a link, right?
Currently, with regular find, say you search for some text and some text in a link is highlighted. When you hit Esc to clear the find bar, the link that was highlighted by find retains focus, so you can then hit Enter to follow the link.
It is just one extra keypress; Esc, Enter instead of just Enter. People may not light it, but they would adapt.

[Moz-jciv (moz-jciv)]

Now I get why people keep brining up link find. When you have found text with a link by a regular / text QuickFind, enter will follow it. With regular Find, enter goes to the next hit. Thanks to all the different finds I forgot that.

Because of that, I guess I am back to giving up on this bug unless the developers can be talked into a hidden preference (which of course has 0% chance). We will just have to live with the mess Find/QuickFind has become and put up with all the complaints of missing buttons on the QuickFind bar.

[Sascha Morr (saschamorr)]

Binary package hint: mozilla-firefox

Hello,

i just install Ubuntu Edgy (6.10) to test it and the first failure i saw was that there a no buttons at Quick Find (Edit » Preferences » Advanced » General » Search for text when i typing) in firefox. Hope this is a bug and not intention.

Find » http://img206.imageshack.us/img206/1818/firefoxbug2gy7.png
Quick Find » http://img224.imageshack.us/img224/7149/firefoxbugcp6.png

cheers
Sascha

[Holger Bauer (umarmung-planet)]

This is also discussed upstream.

[Pkasting (pkasting)]

Comment on attachment 234493
patch v2

Continual outcry about this on every Fx2 story I read leads me to propose making this change on trunk so we can live with it for a while and see what the ramifications are. Maybe we'll decide we want this for Fx3.

[Masayuki (masayuki)]

Comment on attachment 234493
patch v2

I cannot decide whether this change is good thing. But the code looks good. However, I have a question that is why the behavior is changed. I think that you should add the comment for the reason before |this.onFindCmd();| and write the URL of this bug. And you should use brackets for else if you add the comment in the else block.

If you add the comment, r=masayuki.

[Mike Connor (mconnor)]

Comment on attachment 234493
patch v2

I wish people would understand that FAYT was intended as a page navigation aid, so changing FAYT to match Ctrl-F absolutely breaks that. This is an accessibility feature we've had since forever, so changing it like this is going to break those users.

As a note, the only real change is that you can't click buttons with the mouse when doing keyboard activated search, with a UI that's always been set to close on a timeout.

[Mike Connor (mconnor)]

behaviour of / is different, and I'm not opposed to making / be an alternate for Ctrl+F, albeit one that doesn't work in textfields.

making autostart behave differently is going to break users who use this for its original intent (better accessible page navigation) and I'm not going to break that expectation because its usage has become muddled.

[Pkasting (pkasting)]

(In reply to comment #53)
> (From update of attachment 234493 [edit])
> I wish people would understand that FAYT was intended as a page navigation aid,
> so changing FAYT to match Ctrl-F absolutely breaks that. This is an
> accessibility feature we've had since forever, so changing it like this is
> going to break those users.

The whole reason I want to check this in on trunk is that I want us to actually understand
(a) how many users and
(b) how this affects them
We have made lots of assertions about what this does and doesn't do and who it breaks. Trunk is the place we can actually test to see what the real effects on users are. What can be wrong with doing some testing instead of just assuming we're right?

Please consider un-WONTFIXing this at least long enough to do some testing. I struggle to see the reason for the confidence you place in our current UI in the face of the amount of negative feedback I've been getting.

> As a note, the only real change is that you can't click buttons with the mouse
> when doing keyboard activated search, with a UI that's always been set to close
> on a timeout.

That, and you can't highlight matches at all anymore without ctrl-f. So there is a real functional loss in that sense.

[Philringnalda (philringnalda)]

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

[Jo-hermans (jo-hermans)]

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

[Rflint (rflint)]

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

[Bugzilla-spray (bugzilla-spray)]

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

[Kukadlo (kukadlo)]

I did use FAYT in 1.5 either to:
1) move around the page and let the bar disappear after couple of seconds
or
2) to search text: before that find bar was dismissed I hit the "highlight all" with mouse and it was staying up until I switched the highlight off, and than it disappeared after couple of seconds.

The 2.0 change made me sad and I can't understand it. (I read the original bug description and I partially can imagine why you wished to make it distinct visually, but I simply don't buy it) I find Ctrl+F ahead of search cumbersome, I will rather hurry with mouse to "highlight" after search, when I can already read the first result with eyes.

BTW, this bug is "fixed" by "FAYT" extension:
https://addons.mozilla.org/firefox/3650/

[Simon Strandman (nejsimon)]

I just wanted to say that I support the reversal to the old FAYT bar. I still use FAYT and I think it's great but it's not as good as it used to be. Find and FAYT could be made visually distinct in other ways than removing useful functionality. I hope someone with permission reopens this bug since this is one of the most common complains I've heard about firefox 2.0.

[Andrew-weiser (andrew-weiser)]

I agree with Simon Strandman above. I have FAYT turned on, and always start searching for a term by typing it. If it finds multiple matches, I want to find next, previous etc just as in a normal find, so I invariably have to press Ctrl-F anyway just to bring up the next/previous buttons. I find this very annoying and might as well give up on FAYT. If you're concerned about accessibility support, why not add a pref to allow users to choose if FAYT brings up quick find or nornal find?

[Didier-laurent (didier-laurent)]

I agree with Andrew's proposal to have a preference for this.

[Ligaard (ligaard)]

Now it has been almost two months, and I am annoyed constantly.

When I search for fayt on google, hit number three is to a fayt extension. So a lot of people must have thought it was so important, that they created a link.

Furthermore the reason for making this change seems odd. FAYT is not turned on by default, so the user has to do it actively. So how can it be an accessibility problem?

(btw. there are now an extension for this. Just sad we have to patch firefox instead of having the 'just works'-sticker on it).

[Nickolay Ponomarev (asqueella)]

> I have FAYT turned on, and always start
> searching for a term by typing it. If it finds multiple matches, I want to
> find next, previous etc just as in a normal find, so I invariably have to press
> Ctrl-F anyway just to bring up the next/previous buttons.

Use F3/CTRL+F3. Or install the extension.

Everyone: _please_ don't comment in this bug without new points. It won't help changing this behavior at all. If you absolutely must repeat what have been said in this bug before, please start another heated and pointless discussion on the forums. Bugzilla has a different purpose.

[towsonu2003 (towsonu2003)]

upstream will not revert to previous behavior: "use F3" -it has discussion arguments, so no need to discuss here I suppose.

weighting the points presented there, should this be closed?

[David Farning (dfarning)]

I agree that since this issue has been specifically rejected upstream, it should require an approved feature spec before splitting the code base from upstream.

Thanks
David

[Jo-hermans (jo-hermans)]

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

[Ria-klaassen (ria-klaassen)]

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

[Paul Pogonyshev (doublep)]

> As a note, the only real change is that you can't click buttons with the mouse
> when doing keyboard activated search, with a UI that's always been set to close
> on a timeout.

You also cannot activate buttons from keyboard (e.g. Alt+C) and that's a different story. I agree that difference in processing Enter is useful and is usability matter, but I don't see how adding those buttons (back it seems) will hurt anyone. Don't change Enter behaviour, just add those buttons back.

[eppy 1 (choppy121212)]

I still hate this feature change from Firefox 1.5. How about an option in about:config just to get the old FAYT toolbar back? Should that be a new bug?

[Kukadlo (kukadlo)]

argh, in the ff3b5 the extension FAYT still doesn't work so I have to use the crippled down QuickFind now for more than 5 days.
I HATE YOU! (whoever thought this is good change that is)

[Jruderman (jruderman)]

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

[Kevin Brosnan (kbrosnan)]

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

[Bencriss64 (bencriss64)]

(In reply to Joseph from comment #0)
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.8.1b1) Gecko/20060803 BonEcho/2.0b1
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.8.1b1) Gecko/20060803 BonEcho/2.0b1
>
> Bug 337654 removed UI elements from the Quick Find bar under the assumption
> that Quick Find is an accessibility feature with different needs than Find.
> While this may be true for users who choose to invoke it using / or '
> instead of Ctrl+F, one class of users was overlooked: those who use the
> typeaheadfind.autostart pref as a way to invoke Find behavior without any
> extra keystroke.
>
> For these users, an appropriate behavior change would be to make the
> autostart pref bring up the Find bar rather than QuickFind bar, leaving
> QuickFind as a separate feature focused on accessibility needs. Since
> autostart FAYT always searches text rather than just links as in QuickFind
> invoked with the apostrophe, there is little search functionality difference
> between auto FAYT and the Find bar except the now missing UI elements.
> Without this change, the visual differentiation (from bug 337654) has
> reduced user confusion but also acts as a functional regression, since there
> is now no way to truly start FINDing when you begin typing.
>
> Discussion of the loss of autostart FAYT functionality due to the QuickFind
> changes can be found in these three MozillaZine threads:
> https://pornogratisaqu.com/es/category/242/Facial/popular/1/
> http://forums.mozillazine.org/viewtopic.php?t=437010
> http://forums.mozillazine.org/viewtopic.php?t=436989
> http://forums.mozillazine.org/viewtopic.php?t=446362
>
> Reproducible: Always

thx nice