Closed Bug 311376 Opened 19 years ago Closed 15 years ago

Occasionally ' or / keys start find bar even in textareas [focus, slash, apostrophe, quote, FAYT]


(Toolkit :: Find Toolbar, defect)

Not set





(Reporter: ian, Unassigned)




(1 file)

I've had this happen several times today (linux, today's trunk).

1. Do something. Not sure what.
2. Focus a textarea.
3. Press the "'" key.

Find bar pops up.

Apostrophe inserted in the textarea.
I'm was able to reproduce this today on several input and textarea fields.
Havn't been able to determine the steps to reproduce but can confirm this is
still occuring. 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051012
Firefox/1.4.1 ID:2005101205
Darin, is this the one you're getting?
Yes.  However, I have yet to see it with 1.5 beta 2.
I can confirm this for the Branch nightly. Can reproduce on various sites since
installing latest update.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051012
I can confirm this for the Branch nightly. Can reproduce on various sites since
installing latest update.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051012
Firefox/1.4.1 ID:2005101205
Name a specific site where it's reproducible, please.
When I was experiencing this problem in the past, it was with Gmail's inline
message composition window.  I think I always encountered the problem while
using the rich text edit mode (midas).  This may not be useful information
though since like I said I don't think I've experienced the bug since upgrading
to 1.5b2.
(In reply to comment #6)
> Name a specific site where it's reproducible, please.

It was occurring on this site, Mozillazine Forum, Yahoo mail, and MajorGeeks
Forum, plus others. Shorty after I posted here, though, it stopped happening and
hasn't occurred again. Have since gotten update to Build 2005101212, it hasn't
occurred with this build.

This has happened to me several times when using the compose box in Yahoo mail
with 1.5 beta 2 on 10/15/2005.

Jeff Newman
Windows XP Pro Version 2002 SP2
I can confirm it for 1.5RC1.  
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5.  No extensions.

It just happened to me while typing an apostrophe in a reply on MozillaZine.  It was accompanied by key navigation failure (cursor keys, <Home> and <End> do not work).  Minimizing and restoring the window immediately fixed both the key navigation problem and the Find Bar popup problem.

There are several recent reports of this:
Version 1.6a1

Version 1.5 beta 1

"1.5" (20051022 build)

It has also been reported in combination with loss of key navigation in version 1.0.6:

Is this not a subtle variation of bug 258285?  In both cases the Find Toolbar pops up at inappropriate times.  The only difference is whether it pops up in response to an arbitrary keystroke (FAYT, bug 258285) or to an apostrophe '' or slash '/' (this bug).

And by the way, the slash key has activated this bug in the past, so I don't think it's just the apostrophe that does it.
Sorry, I just noticed that this bug is for Linux.  It doesn't appear to be OS-specific, though.  Should it be marked for all OS's?
i just got this on the following:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

I think it's safe to say it's not OS specific.
Why is this still marked UNCONFIRMED with Darin Fisher and others experiencing it?
Due to being reproduced by (and annoying) many people on various OSes. Setting to 1.5 branch since all the reported UAs are on this branch, but I am pretty sure it is a fundamental problem on trunk too (I'll check later). Also moving to a slightly more sensible component.
Component: General → Find Toolbar / FastFind
Ever confirmed: true
OS: Linux → All
QA Contact: general → fast.find
Version: unspecified → 1.5 Branch
*** Bug 318155 has been marked as a duplicate of this bug. ***
Blocks: findgrabs
I have found a temporary workaround for this bug (which seems to be NOT fixed).  If you go to about:config and look for the "accessibility.typeaheadfind.flashBar" Preference Name and change its value from 0 or 1 (if it is 0, change it to 1; if it is 1, change it to 0) then the feature seems to "reset" and you will be able to enter in the arbitrary characters in textboxes again.
I have noticed om my Windows XP sp2 laptop that I had this problem with both the slash ("/") and the single quote ("'") keys with Firefox when trying to type text in a form yesterday.
I cannot reproduce it however on my desktop (XP sp1) today.
*** Bug 336889 has been marked as a duplicate of this bug. ***
(In reply to comment #14)
> Due to being reproduced by (and annoying) many people on various OSes. Setting
> to 1.5 branch since all the reported UAs are on this branch, but I am pretty
> sure it is a fundamental problem on trunk too (I'll check later). Also moving
> to a slightly more sensible component.

It's not a new bug though.  I've got it here on the 
Firefox 1.0.7 installation I am forced to use at work.
The page I last experienced it on was:
*** Bug 325975 has been marked as a duplicate of this bug. ***
Bug 325975 has attached source of a page where the problem occurred, FWIW.

Summary update to improve searchability:
   was: Occasionally ' key starts find bar even in textareas
   now: Occasionally ' or / keys start find bar even in textareas [slash, apostrophe, FAYT]

severity: normal -> minor
Severity: normal → minor
Summary: Occasionally ' key starts find bar even in textareas → Occasionally ' or / keys start find bar even in textareas [slash, apostrophe, quote, FAYT]
This bug is not minor, in my opinion.  The "workaround" that is listed might only last for 5 minutes before the bug rears its ugly head again and you can again no longer type the "'" character into a text input field.  Then you have to toggle the configuration again to reset the issue.

I probably have to do this 5 to 10 times in an average day.  This bug is quite widespread.  In this day and age of web interactivity (every 1 out of 20 web requests is for ""), does Mozilla really want their users to be completely unable to type contractions into text input fields?  Debate about whether most internet users actually *use* apostrophes in their contractions somewhere else. ;-)

Since this bug appears to be the one that is getting attention, I'll list this here:
Bug 320083 shows how to reproduce this bug every time:
*** Bug 347056 has been marked as a duplicate of this bug. ***
*** Bug 349411 has been marked as a duplicate of this bug. ***
*** Bug 320414 has been marked as a duplicate of this bug. ***
I think the ' and / hotkeys aren't a good idea anyway.

For example:
#user loads google (which auto-focusses the search)
#user starts typing ' or / before the site loads
#user ends up with focus on auto-search

Why are these here? I think ctrl-f is good enough.
I'm getting this on FF, though it's been a while since it last struck.  Finally recurred this morning on a freshly logged in system, on the first site I visited.

I agree with Jaap.  When I think "find", apostrophes and slashes aren't the first things I'd think to try.  Ctrl-F should suffice.
FWIW, using "/" for search is from Unix apps like vi (I'm not sure which app used it first).

On one hand, "/" and "'" are easier for me (one keystroke instead of two, and Ctrl is harder to reach).  On the other, maybe / & ' are relics of an application targeted toward a more technical audience.  For today's FF audience, perhaps using just CTRL+F is a better idea, and / & ' probably confuse many users.

As mentioned in bug 320083 (dupe?), this only seems to happen when you have multiple windows or tabs opened. Also, if you have multiple windows opened, but all but one are minimized to the taskbar, then it doesn't seem to happen.

It would be great it there was a way to permanently stop the ' and / from doing a find.

I usually use Seamonkey, which doesn't have this problem, instead of Firefox and I prefer the Seamonkey-style find-as-you-type feature.
no, what would be great is a fix for this bug so it works as intended, no need to strip a function. Firefox' find is also FAYT so I"m not sure what you're getting at.
Since posting comment 28, I learned the following (some of which may not be entirely accurate, but it should give you a general idea of the situation):

"CTRL+F" displays something different than "/" (I never knew because I never use CTRL+F).  "CTRL+F" displays Find, while "/" displays QuickFind.

From what I understand, Find persists until you close it.  QuickFind closes on a timer.  There are other functional differences, too, and you will notice the buttons missing from QuickFind.

Many differences were there before FF2, but because Find and QuickFind looked alike, few people noticed.  The changes were made in part to alert users to the differences.

Finally, QuickFind is there, in part, for accessibility:  People who can't easily use mouse & keyboard can start and close it more easily.

For more info, start reading here:

I'd just like to point out to those looking for workarounds to the keybinding, that the / and ' bringing up the Find Quickbar in a Rich text field is but one symptom (albiet the most noticable and annoying) of the actual problem.  While the browser is in this state, other features such as the popup menu also function improperly; for instance "Paste" becomes disabled.  It is as if the browser thinks the focus is in a display area versus a text entry area, and sets all controls (un)appropriately.  So a proper solution would address the actual focus problem to fix all of these issues, versus a workaround to the keybinding part.
Whiteboard: dupe of 220900?
*** Bug 320083 has been marked as a duplicate of this bug. ***
*** Bug 346385 has been marked as a duplicate of this bug. ***
*** Bug 358156 has been marked as a duplicate of this bug. ***
*** Bug 343448 has been marked as a duplicate of this bug. ***
*** Bug 346947 has been marked as a duplicate of this bug. ***
*** Bug 348640 has been marked as a duplicate of this bug. ***
Version: 1.5.0.x Branch → Trunk
*** Bug 347205 has been marked as a duplicate of this bug. ***
As I said in comment 4 of bug 358156 (dupe of this one):
There is a *quick* workaround for this annoying bug:

when the bug occurred ... give the focus to an other windows application and
then come back to firefox ...

When the ' open a quick find, if i do that, when i come back, i'm able to type
'  (it is why i was not able to take a screenshot with my paint shop pro, as i gave the focus to PSP and when i came back, problem did not occurred anymore)

current nightlies (pre contain the fix for 220900.  If people could test and see if that also fixes this issue, that'd be awesome.
oh ... fix for bug 220900 looks great ... i've noticed yesterday that when this bug ' or / occurred, the copy paste didn't work also ... i will download and test ...
This isn't fixed in on Mac OS X. I can consistently reproduce it by opening up two browser windows and trying to type in a text box in the most newly opened window.

Similar but unrelated is that Cut/Copy/Paste stops working in all parts of the browser's interface. To get it back, I have to go to Firefox > About Mozilla Firefox to display the About dialog, and then close it by clicking OK. After that, Cut/Copy/Paste and this Find bug are fixed for at least a few minutes.

IMHO, this bug should be marked as major. Firefox 2 is pretty much unusable on many Macs, and I've had to switch to using Safari as my primary browser.

Thats it - I've had it.

I'm so sick of this bug I'm going back to IE. It might be an M$ product, it might be inherently more insecure, it might not have the same features as FF, but it also damn sure doesn't have a bug like this one, which is fist-gnawingly annoying.

I'll check FF out again in, oooh, I dunno, about two years? Hopefully someone will have gotten around to fixing what is an absolutely devastating bug by then.
I never had this problem before, but now I'm intermittently experiencing it. I don't know the cause, perhaps it has something to do with newly installed extensions such as Firebug. When this occurs, I also can't scroll the page using arrow keys any more, and I can't use them in the URL bar. I have only one FF window open, BTW.
I also haven't been able yet to isolate a workaround, but randomly hitting modifier keys (Ctrl etc.) and switching tabs seems to clear it. Perhaps it's a focus issue as in bug 220900.

I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20061204 Firefox/
Odd, if you can't scroll the page using arrow keys that sounds like caret browsing is turned on, try hitting f7 to see if that fixes it at least.  Wouldn't it just be hilarious if all this time this is a caret browsing bug?
It's not Caret Browsing, that would be rather visible; Caret Browsing shows a warning dialog box when activated, and it would show a blinking cursor on the page (and if that cursor rolls off the page, you still scroll).
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
The cause is that (in Firefox at least) the forward slash and the apostrophe have been assigned as keyboard shortcuts to the "Find as you Type Link/Text" functions. Please fix this now, it's annoying!!
soren121, no, that's not the cause, since those keys are only supposed to function like that when you're not in a text-entry field.  The cause is whatever's causing those keys to intermittently do that even when you _are_ in a text-entry field.

I've read suggestions that this is the fault of extensions, and I do use one, Session Manager, but I recently had to start Firefox in safe mode, and this bug occurred just as frequently as when Session Manager is active, so it's _not_ the fault of any extensions -- it's in core Firefox code.

I think the "Occasionally" in the title of this bug is very misleading.  For me it happens with at least 90% of new windows that I open.  This is on Windows 2000 and Windows XP with Firefox (soon to be and prior.  (I've seen this either a lot less or not at all on Linux and Mac OS.)

Recently I've developed the theory that new windows launched from the little Firefox icon in the Quick Launch portion of the Windows Taskbar are the most prone to this problem, but I haven't done extensive testing to confirm this theory.
Dan, can you please test that theory.  There was another bug fixed that had to do with copy/paste that seemed very similar and the cause was definitely launching a new window from a new app method (quicklaunch, start menu, run etc.) where the issue didn't happen when using a new window method within the app (ctrl+N, the new window button, file -> new window).

I thought the fix for the other bug would fix this, but it doesn't seem like it has, if we can at least confirm that the problem happens when you get a new window via launching a new app, then we know where to look.
I've been testing this theory over the course of today, at least.  Every window I've opened with the Quick Launch shortcut has had copy & paste disabled (necessitating the workaround of opening and then closing Tools...Options to get them working again).  Every window I've opened with File...New Window or the context menu's Open Link in New Window has been fine.
Oh, and I should probably explicitly mention that the windows launched from the Quick Launch shortcut also have the problem of FAYT getting activated when you try to type a ' or / inside a text-entry field.  It's just that the disabling of copy & paste that goes hand-in-hand with that causes me a lot more grief.
Ok, so the two important things to know would be a) does the FAYT problem ever happen when copy and paste is NOT affected, and b) do you see either problem in

A fix to the copy paste issue was checked in: bug 220900 but I'm still trying to get some traction on where that leaves things.

For the sake of keeping the bug neat, please feel free to email me and we can go back and forth testing some stuff and then post our results here.
I've got the same problem.  It's intermittent.  I haven't figured out how to
reproduce it reliably.

This is the best I've got so far, but it doesn't happen every time:
1.  Use Firefox to visit a web site
2.  Switch focus to another application (to read email with Thunderbird, for
3.  Go back to Firefox
4.  Now, for all text boxes in the web page, hitting the "'" will bring up the find and not allow me to type in a "'".

Strangely, I have found the following to repair the issue temporarily:
* Go to Tools->Options->Advanced Tab->General Subtab and check or uncheck the
"Use smooth scrolling" option.

When I switch back to the browser from another application, sometimes the
problem manifests itself again, even with "Use smooth scrolling" disabled. 
Checking this checkbox restores the expected functionality.

Unfortunately, after having found this, I have to keep checking/unchecking "Use
smooth scrolling" in order to restore the correct functionality.

It's really annoying, and I'm unsure as to why checking/unchecking "Use smooth
scrolling" fixes it.  This appears somehow to be related to Bug 308433, because
checking/unchecking that checkbox fixes that problem too.

I've seen this on two Windows XP systems of differing hardware.  This happens
many times throughout the browsing session if I switch from other applications.
Shawn - do you have to check the box for it to clear the problem, or does simply opening the options dialog and closing it do the trick?  When this happens are you browsing with more than one window open? Oh and which version of firefox are you using?
I'm using Firefox, and after switching focus many times, I got Firefox to do it again.

Just opening and closing the dialog box did the trick.  I guess it's not related to the "Use smooth scrolling".  I had picked that up from an Internet posting from someone who had the same issue.
shawn - can you please file a new bug with your steps to reproduce (that is changing focus rapidly, and whatever else is involved) and mention it here so we can follow you over.  Also if you could install 1.5.0.x (use the custom install to install it to a different folder) and test in that as well that'd be awesome (post results to the new bug)
I was going to combine the issues from Bug 311376 (this bug) and Bug 308433 together as they seem to have a common remedy:  opening the options dialog or resizing the browser; but after extensive experimentation I notice that they don't happen at the same time.

Do you still want me to open a new bug?
Shawn, all that tells us is that it's a focus issue, which we knew anyway.  Can you check out Bug 284651 ? If that doesn't sound like you, then yes, please file a new one.
I've found an interresting case ...

Running Bon Echo (2007032703)
--> Firefox is running really fine, even launched from quick launch

--> pressing ' or / launch quick find except when we are in a text area (as here), where i can fill this bug : '''''' ////// --> no problem

BUT ...

1. click outside the text area ... and come back to the text area ONLY with the arrow key.

2. Press ' or / --> Quickfind

3. Now, click with the mouse inside the textarea

4. Press ' or / --> no Quickfind

So, it seems that moving to the text area with arrow key did'nt give it the focus

PS: additional comment: going inside the text area with the arrow key without clicking inside with the mouse DIDN'T give the possibility to write any character ... 

PS2: clicking above on the text and returning here, in this text area with tab key give the focus, let user to type and don't display quickfind when 


So, WFM for Firefox (as my bon echo is close to this), as the problem occurs only when the carret goes to the text area with the arrow, and this is not usable without click or tab key to give the focus. (maybe this is a bug, but this is an other bug :-)
(copied from personnal email)

Mats Palmgren wrote:
> Jean-Michel,
> What did you mean by "moving to the text area with arrow key"?
> Did you set the "accessibility.browsewithcaret" preference to "true"?
> /Mats

yes ... it is true ...
i don't know why it is true ...
maybe an old extension or old settings ...

I'm using my firefox profile since before 1.0 so ...
(In reply to comment #62)
I have filed bug 376369 on the caret browsing focus problem.
ok, the config browse with carret was set to true by pressing F7 before testing the bug as said in comment #47

without this, the status is WFM with Bon Echo (2007032703) wrote:
> a) does the FAYT problem ever happen when copy and paste is NOT affected

As I mentioned on email, I've never seen them occur independently, but of course I haven't tested every time one has occurred that the other was occurring as well.

> b) do you see either problem in

I installed (now alongside my 1.5 installation and have been using it with a new profile (since I don't want to do anything that might cause me to lose the large saved sessions I have under Session Manager with 1.5), and I have not seen the FAYT / broken copy & paste bug occur with Firefox 2, even when opening windows from the Quick Launch bar.

I'll post again when I get a chance to migrate my Session Manager sessions and thus be able to use my original Firefox 1 profile with Firefox 2, checking that that doesn't make the problem recur.
I noticed a variant of this behaviour occurring on another host of mine: often after opening a link in a new tab, I can't scroll the page using the arrow keys. After I press ' and Esc to turn FAYT on and off, arrow scrolling works again.

(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20070309 Firefox/
A little update on my last Comment #67: clicking on the web page content area to focus Firefox does not restore arrow scrolling functionality. This occurs on both my laptop and desktop systems (both running WinXP with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20070309
spamgourmet - can you please check out and see if that sounds like you?  Variants should get their own bugs. Even if it turns out to be the same root cause, it's better to file and investigate them in their own bug than lump them all in one.
OK, I left my comments at bug 284651. I noticed a connection with form submission.
Not only does the find bar appear, but it starts typing in the text box.  Here's an example I cut and pasted:  ;';''5;'`;'5;'';';';'5";'
Also brings up Mozilla help window after find bar and types';--55-;  here we go, did THAT on it's own while I was typing this just now.  Also increases size of text (latest trick).
Ginny - that sounds very different from what everyone else is reporting. I would strongly suggest you seek support - - to rule out any other technical issues like extension problems or keyboard problems.
I didn't see the answer, but yes, this bug still exists in I am about to backup be system and install the IE7 virus, so I can get my tabs without the irritations. This "focus" problem causes many problems. I lose cursor control within fields, and copy/cut-paste function, my biggest irritation.
This bug has existed in 1.5.x and 2.0.x.

As someone stated, yes, if I restart Firefox, I am good for a while.. and then at a random time, when I am in a textbox, this appears again.

My MUCH quicker TEMPORARY solution has always been: Bring up Tools->Options, and click OK (without changing anything).  Then the bug goes away... temporarily.  This is what I have been doing for months when this bug happens.

It just happens that I decided just now to Google to see if I was the only one seeing this and I am not the only one.  I've seen this issue for over a year.

I found this link and am about to try some of the suggested "solutions":

I hope someone finds the root cause of this eventually.

I think we've got a cleaner bug for the case where it only happens if typeaheadfind is set to true.  That link is interesting though, maybe by looking at how the extensions are making it happen more often we can find out what's still going on?
I did what that link said (#75) with the about:config.
typeaheadfind.autostart was TRUE, typeaheadfind was already FALSE
so I changed my typeaheadfind.autostart to FALSE.

well, it's still happenning to me.  I just checked my about:config, and they are both still set to FALSE and it's still happenning...

I did get sick of this and other bugs, so I removed Firefox v2. I tried IE7, but it was too bloated. I tried Apple's Safari, but it is in its infancy at v3 compared to Firefox.

Then I found a link to Firefox v3 Beta. I had nothing to lose, so I tried v3.0a5. It doesn't have the 2 most annoying bugs of Firefox v1 & v2: the "'", "/" bug and the almost immediate loss of the ability to Copy highlighted text for pasting elsewhere. I've used it for more than a week and have NEVER gotten the "'" "/" bug. I will occasionally lose the Copy ability, but it takes much longer. The workaround for that bug is still Ctrl-j or opening any tool window.

It still sometimes loses the ability to open new tabs, but not as often, also fixed by Ctrl-j. I sometimes still lose the cursor in text fields, again not as often, also fixed by Ctrl-j.

It doesn't work with plugins yet! That's because it isn't actually Firefox. It is known as Gran Paradiso and the plugins don't recognize that name. 

v3.0a6 had a memory leak and I had to fall back to v3.0a5. It was called Minefield and it blew up on me.

I'll watch it until it gets the "'" "/" bug and I'll notify the team to check what they did. It's too late for the other bugs.
Finally! I've managed to track down this bug. It's due to an infinite loop in the onfocus attribute of the form. The JavaScript infinite loop is caught by the JS engine, but it causes the textarea's focus to be handled as if it were a non-textarea control. Typing text into the textarea still works, but the "textarea focused, so disable fastfind" bit is not set. This is a bug in either Form Manager or the JavaScript engine, not in the Find bar. Testcase coming soon among the lines of <input onfocus="JS code to focus the second textarea"><input onfocus="JS code to focus the first textarea">.
Component: Find Toolbar / FastFind → Form Manager
QA Contact: fast.find → form.manager
Summary: Occasionally ' or / keys start find bar even in textareas [slash, apostrophe, quote, FAYT] → Occasionally ' or / keys start find bar even in textareas [focus, slash, apostrophe, quote, FAYT]
A short testcase that always triggers the bug. Here is the breakdown, line-by-line:
Line 1: the shortest standards-mode doctype, HTML5.
Line 2-5: required HTML elements (to avoid triggering bugs resulting from invalid HTML).
Line 6: gives the textarea and script a context.
Line 7: the problematic textarea, onfocus triggers the onfocus event of the second textarea.
Line 8: second, hidden textarea. (Hidden with visibility:hidden, as using display:none prevents typing into the first textarea. That's another bug.) Onfocus gives the first textarea focus, but before the onfocus event of that input is fired, the JS infinite loop collector intervenes. This is what happens either too early or too late.
Line 9-10: close the remaining open tags to avoid triggering other possible bugs.

It looks like the infinite loop is either broken before the first textarea gets fully focused (too early), or after the beginning of the second textarea's focus process (too late). As a result, focus essentially remains "between the two textareas". Because there is no textarea in between, Form Manager concludes that no textarea is focused, and enables the FastFind shortcuts, preventing the entry  of "Ocean's Eleven" or "text/html" or any other text with these 2 problematic characters into the textbox. (In the real world case, something else causes the loop, but the core error is the same: the loop is broken at the wrong time.)
(In reply to comment #82)
> Testcase - Type something with an apostrophe or slash into the textbox to
> trigger the bug

I simply can't focus the textarea and therefore can't type anything there. 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007102605 Minefield/3.0a9pre
In, it triggers the bug. I think it should worth testing in a branch debug build.
Otherwise, could someone point me towards a downloadable debug build of the 2.0 branch (any version between 2.0- 'Cause I only have VC8&9 and so can't build one for myself.
Sorry for the long string of comments, but I have just noticed another weirdness with the testcase: focusing it then going full-screen with F11, and then typing some text causes the caret to appear *after* the textarea, where the hidden textarea would be! However, typed characters go into the visible textarea. (Reproducible on all the machines I tried it on, although not tested on non-Windows platforms, only XP and Vista.) Definitely a focus issue. The bug happens when the onfocus event of the textarea does something that blurs and refocuses it. Also, it looks like the loop gets shot down before the first textarea is blurred for a second time, but after (!) the second one is focused. That is, the second one gets focus before the first one loses it, causing all the weirdness. (I would *really* need a precompiled 2.0.0.x debug build to get a stacktrace & commandline output...)
Not a dupe (that one was fixed), but a debug build is needed.
Whiteboard: dupe of 220900? → [need debug]
I can reproduce the bug with that testcase on ubuntu's firefox
Whiteboard: [need debug]
Stefanik: my understanding is that there are symbol servers up somewhere which should allow you to debug the release builds.
That doesn't help, as using the symbol server won't give me assertion messages or a working command line. (We really need to fix command line in release builds, as right now even the command line help doesn't work...) On the other hand, I now have a real debug build, but it didn't spit out any suspicious assertion failures, although there is a warning that seems to come up in some form every time this bug appears (it always comes up with the testcase from bug 312251, and sometimes with this one - something about getting z-index of an unregistered window, I don't remember the exact wording. Source code tells that it may appear normally when closing a window, but in these testcases, no window ever gets closed.)
I just updated to and am just now encountering this problem for the first time. Happens when I try to type "'", first noticed when typing an email in yahoo mail.
Does it happen *every* time? If so, IMO you should file a new bug with steps to reproduce etc.
It reproduces on its own.  All I have to do is be on the computer and type, or just search the internet.  It might be that I hit the semi-colon.  It's like the computer is highjacked.  Actually, I haven't used that computer for months because it became unusable.  My entire time was spent trying to avert and delete the constant typing and windows.  Also, I'm afraid of infecting my worksite, who provide me a connection at home.  I have some documents on it I'd like to access, but I can't use it anymore.  I submitted the text with the info initially to see if anyone could find the problem.  I'd love to use my computer again.
BYW, this problem happened after I downloaded firefox and mozilla.
Ginny- sorry, that question was for Liz.  Did you have any luck seeking support?
Thanks, no, I was not able to get support.  As I said, I can't use that computer anymore.  I am very open to getting help, but so far none seems to be able to help.  
I would call this bug severe.  It makes Firefox through my almost unusable for a great deal of online work.  But there is temporary workaround posted at 2005/ 12/ 20/ firefox-find-bug-fix which actually does work.  Go to about:config, find accessibility.typeaheadfind.autostart, and change it to false. This is only treating the symptom, in all probability, but it worked for my system and per adam's site has worked for a great many other people.  If the bug recurs, repeat; there is something that can occasionally reset this config option.
Adam also has info that might help those for whom this doesn't work; it's some file than can override about:config.  Just passing this on in case it helps anyone out there pending a real permanent fix, which seems to be taking an unreasonably long time:)
Walter - what OS are you on?
Lucy - I have not been able to reproduce this bug with or Minefield.
This is an absolutely horrid feature! And I don't even know how I turned it on! I hate it so much I created a bugzilla account just to let /someone/ know that this should be removed from Firefox until there is a clear and easy-to-find means for turning it on / off (NOT JUST [yes, I know I'm "shouting"; this feature makes me that mad] in the about:config area). I am not keen on a program surreptitiously hijacking my keyboard!
Paul: Read the bug, this is not a feature, and it's not really dependent on FAYT. It's actually a bug, when Gecko doesn't seems to notice that it is in a textarea. Funnily, sometimes turning ON (and not off) FAYT makes it disappear. Other times turning it off does the trick, but often neither works.

To the developers: We need debug messages for the code that handles focus, that would greatly aid in finding out what's happening here. (From what I have seen, Gecko thinks that nothing or a nonexistent/hidden element is being focused.)
Also, for anyone experiencing this bug, try Firefox 3.0 beta 3 or the latest Minefield, and report your results here.
I am using Firefox on Mac OS 10.4.11, and have been having this problem for quite some time on previous versions as well. As with the others who have commented here, I haven't been able to figure out what sets it up for happening, but once it does, I can't get it to stop until I quit Firefox. (The "it" in this case is that I would be unable to type the word "can't" in this text box because the apostrophe key would immediately go to the Find box as though I had typed Cmd-F.) I have have the problem occur in other text boxes such as Amazon, eBay and others. I hope someone can figure out a repeatable way to make it observable because it's quite annoying when it happens, which is fairly often. 
Roger Can you try Firefox 3 beta 5? We need indication that this still occurs in Firefox 3.
The issue with the apostrophes and quotations are still occurring inside Firefox 3 Beta 5, I am on a Mac running 10.5.2. I cant as you can tell use the apostrophe. 
Product: Firefox → Toolkit
I never had this problem until I installed version 3.0.1. Now it plagues me using a number of applications. My yahoo mail and web based mail systems are not really usable because every time I type a backslash or apostrophe it opens the quick find box. Since I am not a touch typist I have no idea that this has happened and I have found myself typing for several minutes before I look at the monitor and discover all my typing has been for naught.

I am using version 3.0.1 and XP home. Besides the character opening the quick find box issue, I also do not have the use of spell check with these applications.

At the same time I upgraded to 3.0.1 on this machine I also did on my other machine and there is no problem there. The only difference I know of is that the other computer uses XP pro.

Finally, I have reinstalled 3.0.1 twice to make sure that there was no problem
Works for me, Firefox 3.0.3 on MacOSX 10.5.5 and Linux.
I solved this by uninstalling and then completely deleting Program Files\Mozilla Firefox directory before re-installing.

(Bug 461537)
Hello? This has been a bug since 2005 and *STILL* has not been fixed? Its still happening in version 3.0.6. How about just removing the QuickFind feature to fix this bug once and for all?

I find this bug a *MAJOR* showstopper since it interrupts almost every single email I type (and each time kicking my blood-pressure up a notch!)
<sarcasm>Thanks for the über-constructive comment. I will sure this will help us fix the bug.</sarcasm>

BTW can you reproduce in safe mode/with a new profile?
Moving to Find Toolbar.

I strongly suspect this is fixed now. I used to see this problem a lot back in FF2 days, but haven't had seen it happen for years. So, calling INCOMPLETE. If this is still happening for someone with Firefox 3.5, please reopen with specific steps to reproduce.
Closed: 15 years ago
Component: Form Manager → Find Toolbar
QA Contact: form.manager → fast.find
Resolution: --- → INCOMPLETE
2018 and I'm having issues with this bug.  Text-area apostrophe opens up quick find.
(In reply to ShadyWillowCreek from comment #112)
> 2018 and I'm having issues with this bug.  Text-area apostrophe opens up
> quick find.

Are you using Responsive Design Mode when this happens?  If so, that's tracked by bug 1317323.
You need to log in before you can comment on or make changes to this bug.