User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040719 Firefox/0.9.1+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040719 Firefox/0.9.1+ When doing a find-in-page or find-as-you-type, text in text boxes is not highlighted. It does seem to be found (the page scrolls so the text is on-screen), but it is not actually highlighted. This is issue does not appear in FF 0.9.2, so perhaps a regression with the new find toolbar? Reproducible: Always Steps to Reproduce: 1. Go to http://bugzilla.mozilla.org/show_bug.cgi?id=240432 2. Do Edit/Find in this Page 3. Type "highlight" in the Find box 4. Press the "Find Next" button Actual Results: The word "highlight" in the Summary text box is not highlighted Expected Results: The word "highlight" in the Summary text box should be highlighted If you press the "Find Next" button a second time, you will be taken to the third occurrance of "highlight" in the page, which is in the bug description. This third occurrance is properly highlighted. I believe this shows that Firefox is finding the second ocurrance, but simply isn't highlighting it properly.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040719 Firefox/0.9.1+ WFM it only does not highlight content in a <select>

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040722 Firefox/0.9.1+ ->WFM

I'm still seeing this in the 20040722 aviary nightly on winxp If I hit highlight on the find bar "highlight" goes yellow and then, if I press find next and find prev, it gets properly flagged. It seems something in the highlight button code is fixing the issue temporarily. If I reload the page, then the problem returns. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040722 Firefox/0.9.1+

I tested this on two colleagues' winxp boxes today (I've got win2k). Clean install, clean profile. Still seeing it. Reopening. Perhaps the confusion is that this bug refers to incremental find, not the new highlight button in the find bar? I've changed the summary to reflect this. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040722 Firefox/0.9.1+

Confirming; OS -> ALL Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040725 Firefox/0.9.1+ Following the steps, the word "highlight" in the textbox is not selected with "find next". Upon hitting the "highlight" button on the find toolbar, the word is highlighted in the textbox, and "find next" will select it.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040727 Firefox/0.9.1+ I'm also seeing this bug. Moreover, if I hit the highlight button twice, the occurance in the textbox stay highlighted (it is not the case with other occurances).

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040727 Firefox/0.9.1+ I'm also seeing this bug and some new bugs, but I don't know, if they have been already filed into bugzilla... If you (after typing "hightlight" - following the steps for reproducing the bug given by the reporter of this bug) press the "highlight" button in the find toolbar, the text in a textbox becomes also unclickable an can't be de-selected.

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

do we still need a more isolated test case, or is there enough to go on to close this bug or fix it? I'm not sure I can reproduce either.

(In reply to comment #9) > do we still need a more isolated test case, or is there enough to go on to close > this bug or fix it? I'm not sure I can reproduce either. Chris, I'm attaching a test case that shows what I believe is the same bug, but in larger text input boxes. In text input boxes that have more than one line of text, text is sometimes highlighted on incremental find but it is not likely to be the text you searched for. Try the following with the attached test case: 1. Edit / Find in this Page 2. Type "entry" in the Find box 3. Press the "Find Next" button (the text outside the textarea should highlight) 4. Press the "Find Next" button a few more times When I do this, I see strange highlights (or no highlight) for each press of "Find Next". Sometimes a whole line is highlighted, sometimes two, sometimes nothing. On the fourth press of "Find Next", the textarea scrolls. I believe this shows that the text is indeed found but just not highlighted properly. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040802 Firefox/0.9.1+

Want to see some kind of progress here within a week, or it's gone.

I just checked this on a trunk build without the find bar using the "old" FAYT, and I get the exact same result you are specifying for the Find Bar. While it is a bug, it is not caused by the implementation of the new find bar. The new find bar code is based on the old FastFind code, and the old FastFind code also does not highlight the word "highlight" in the Summary text box in your example.

blake, any update?

> When doing a find-in-page or find-as-you-type, text in text boxes is not > highlighted. It does seem to be found (the page scrolls so the text is > on-screen), but it is not actually highlighted. This is related to bug 189039. To cut the story short, if you don't use find-as-you-type _at all_ (so that the FAYT is never initialized), then find-in-page works fine in text boxes. But as soon as you use FAYT a first time, it installs an observer and start _stealing_ find-in-page. That is, even though one has the _impression_ of doing a normal find-in-page, it is actually going through FAYT. That's where the problem comes from because FAYT doesn't highlight matches in text boxes. To verify this, simply reload and go straight to find-in-page, and you will see that every works fine.

For PR1, we're not going to find text in textboxes. Patch checked in. Moving to 1.0+.

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

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

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

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

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

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

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

So I need to use 0.9.3 if need to find text in text boxes? Is there no way I can "turn on" this feature in 1.0PR?

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

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

Tweaking summary a bit based on summary from dupes.

Not a "blocker"

I can't believe the comment "For PR1 we are not going to find in text boxes"!! That is a massive step backwards. It will certainly put wiki users offside: wiki's present users with large prepopulated text boxes, which they definitely need to search in.

(In reply to comment #28) > > It will certainly put wiki users offside: wiki's present users with large > prepopulated text boxes, which they definitely need to search in. > I may add this is a major barrier for bloggers like me as well. I simply need this "find in text boxes" feature every day as I edit my blog posts for clarity, spelling, etc. It is indeed a big step backwards from previous versions and I hope it gets treated with highest priority. Things like these are especially annoying to those who create online content in Blogs and Wikis, which are ultimately the same tech people reviewing browsers, and promoting Firefox (or not promoting it).

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

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

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

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

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

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

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

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

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

In the recent nightlies, it will highlight text in textboxes. But, it still cannot Find text in textboxes. The highlight part is fixed. The only remaining broken part is the Find in textboxes.

It could highlight text in forms already in FF PR 0.10!

(In reply to comment #40) > It could highlight text in forms already in FF PR 0.10! True, only find in textbox is broken. Sorry for spamming but can somebody change the summary to relect this?

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

garbage: please do not mark bugs +. only ADT has the right to do that, unless you have been explicitly told to do so. If you have been told to do so, say as much in the bug.

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

Another wrinkle: if you use the "Highlight" function in Find, it sometimes blocks the user from selecting/overwriting just the highlighted text. The workaround is to make the edit next to the selected text, then select over the highlighted area and delete it.

I totally agree with Philipp Lenssen (Comment #29), that search in textboxes is an essential feature for firefox. For heavy Wiki-Users (as I am for example) it would be a big step backwards if this feature would not be functioning in FF1.0. Hope, that someone can fix this bug until 1.0 (I´d love to, if I just knew how ;-)

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

I extremly need this feature in Wikipedia!!!

That's great, thanks. Now everyone stop saying that. It's extremely late in the 1.0 game and there's no patch for this bug? How is saying "I need this!" going to help? It won't. Bugzilla is not the place to say "me too". Bugzilla is the place to fix bugs. If you have a patch, attach it. If not, quit spamming.

It has been hard to understand why it has not got the priority necessary to get into the next release: afterall, it is something that was actually _broken_ in the current release, with respect to all previous releases. Notice how many dupes there are. People hit this and report it: it bugs them. Saying "bugzilla is for this" or "bugzilla is for that" doesn't help at all. The general Firefox user community doesn't know (or really care) what you think bugzilla is for. Bugzilla is a way to communicate with people who can influence what happens with a bug. It's a way to put one's concerns in writing where they stay for all to see in a relevant place. Similarly, protestations like "if you want it fixed, then fix it or shut up" are worse than useless. Firefox is big time now. You (the 'owners' of it) have been out there publicising it like mad to the general user community, not to just the average open source user base. You are going to get people who don't know or care about how you think the support model works. Saying "stop spamming" to someone who in all liklihood is expressing their concern about a bug in the place that they think is most appropriate only hurts your own image. You might as well say "**** off you ignorant smelly bastard, we don't want your opinions". "Spammer" is no less of an insult. Personally, if there isn't time to fix it, then I think the correct response to this bug would be to pull out the new not-yet-properly-bedded-in find feature and put back the old basic stuff that works properly. Put the new stuff back in when it's really working. Whatever you decide to do, you would serve the image of Firefox better if you quit complaining about people commenting about bugs in bugzill comment log.

Martin: Please read the Bugzilla Etiquette guidelines and then rethink your last comment. http://bugzilla.mozilla.org/page.cgi?id=etiquette.html Everyone else: I apologize for the spam that this comment generated.

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

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

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

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

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

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

Actually, releasing Firefox with such a bug was a CRIME. Really. All that big advertisement, we are so nice, we are so good, IE is so evil, and with Firefox we could not even find text in a page (a big problem for writing in Wikipedia)... so we have to use IE! Yes, it was a crime. It was a crime.

(In reply to comment #58) > Actually, releasing Firefox with such a bug was a CRIME. Really. All that big > advertisement, we are so nice, we are so good, IE is so evil, and with Firefox > we could not even find text in a page (a big problem for writing in > Wikipedia)... so we have to use IE! Yes, it was a crime. It was a crime. Please don't write this kind of message in Bugzilla. It is for the reporting of evidence and supporting information behind a particular bug, not your opinions. They can be voiced in the Mozillazine forums if you wish.

(In reply to comment #58) > Actually, releasing Firefox with such a bug was a CRIME. Really. All that big > advertisement, we are so nice, we are so good, IE is so evil, and with Firefox > we could not even find text in a page (a big problem for writing in > Wikipedia)... so we have to use IE! Yes, it was a crime. It was a crime. Please don't write this kind of message in Bugzilla. It is for the reporting of evidence and supporting information behind a particular bug, not your opinions. They can be voiced in the Mozillazine forums if you wish.

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

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

Fixed in SeaMonkey (Bug 58305) - one could reuse that code/ use it as a pointer - good discussion of the coding issues there, and working code.

Darn, forgot to add one thing: A (popup-blocker-hindered) WORKAROUND from http://bugzilla.mozilla.org/show_bug.cgi?id=58305#c52 : use this searchtextarea bookmarklet http://home.hccnet.nl/m.wargers/bookmarklets/searchtextarea.htm . Sorry for the bugspam x 3.

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

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041221 Firefox/1.0+ Whoa. In my Mac (10.3.7) this bug does not exist. Find works fine the first time whether working from the Edit menu or from the Cmd-F key combo. I always use the latter. This worked in 1.0, too. I use it nearly every day.

(In reply to comment #66) > Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20041221 > Firefox/1.0+ > > Whoa. In my Mac (10.3.7) this bug does not exist. Find works fine the first time > whether working from the Edit menu or from the Cmd-F key combo. I always use the > latter. This worked in 1.0, too. I use it nearly every day. Are you sure you mean the same thing as we do? The bug is that text IN FORM ELEMENTS such as text areas is not found. On my Mac it doesn't make a difference whether I run Firefox on 10.3.6 or 10.3.7.

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

Resetting to ?1.1 I assume garbage accidentally plussed the bug

(In reply to comment #69) > Resetting to ?1.1 > > I assume garbage accidentally plussed the bug Absolutely not accidentally! It was a crime to release 1.0 with such a bug!!! It would be inconceiable to release 1.1 still with this bug! Too many times I have to use IE, just for this bug!

garbage@loz.it: Don't touch the bloacking flags, other than to request them (?).

if we can get a patch please renominate.

garbage@loz.it: Please read comment 72 before you re-nominate.

(In reply to comment #72) > if we can get a patch please renominate. I admit that I have not followed this bug too closely but I distinctly remember this being fixed I forget which build I think it was the preview release, then it was broken again in a later build. What changed???

Anyone as distressed by this bug as I am (and clearly there are a lot) should be *extremely* pleased to discover that this extension lets you revert to the old popup style find dialog, complete with finding in textboxes and carry-over of searches across tabs/windows. I am ecstatic. Go here: http://s93731204.onlinehome.us/firefox/retrofind.html

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

Why isn't this being fixed?

(In reply to comment #77) > Why isn't this being fixed? Please read http://bugzilla.mozilla.org/page.cgi?id=etiquette.html before making further comments.

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

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

Resetting the aviary1.1 flag to -. I'm leaving the other ?'s, but there is no patch, I highly doubt it will be + for 1.0.x. Please don't set the blocking flags to anything but ?, and definitly don't change them unless you have the authority to.

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

Even if there is no patch, this bug has to be addressed before 1.1 final (which still is a month or two away) which hopefully get someone working on this issue since it's essential. Shipping 1.1 with this feature broken will get many people upset. -> Requesting blocking for 1.1 -> Requesting Severity: Major

(In reply to comment #83) > -> Requesting blocking for 1.1 When a flag is marked as "-", it's been denied. Re-requesting it will get nothing done unless you have a decently-coded patch, and if you don't have one you're bugspamming a whole lot of people and annoying the developers. This flag has *already* been switched from "-" to "?" and then switched back to "-" several times, and doubtless I and many others are starting to get annoyed. Whoever requested blocking-1.0.(3|4) would do well to remove them, because I *guarantee* there's exactly *zero* chance of this being fixed in an already-released 1.0.3 or a future 1.0.4 release (or, indeed, in anything other than trunk code).

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

Would it be possible to dissect this extension http://s93731204.onlinehome.us/firefox/retrofind.html include the code with the next version of firefox? After a year of having to use IE in wiki pages to get aroudn this bug, this extension saves the day!!

Still there in Firefox 1.03 - ctrl-F cannot find text in a TEXTAREA in a table. For a live test case, get a Fastmail mail account (http://f-m.fm) , create some text in a Notepad file, then ctrl-F to try to find that text in the textarea. The desired text is plainly visible in the page source, but is not found by FF 1.01, 1.02, 1.03 . IE finds it, and highlights it correctly, by the way.

Version -> Trunk (meaning Firefox trunk). Removing self from cc because this has a WORKAROUND in Firefox, is FIXED in Mozilla, and because of the meritless bugspam/flagspam (sorry, but un-cc-ing will spam most of you anyway...). I'm switching back to Mozilla, as the workaround doesn't work well (Ctrl-G produces a false negative) and I use Mozilla Mail/Thunderbird anyway. Hopefully Bug 58305's fix has made this easier to fix. Bye.

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

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

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

Not in scope for a security release

WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050614 Firefox/1.0+

I bet it doen't. Post a screenshot.

My bad, it dosen't. Sorry for the bugspam.

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

So what is the actual status on this bug? After the initial difficulty of selling Firefox to my organisation's exec committee I've since wound up with egg on my face due to this new bug. I say 'new' because I'm almost certain it wasn't there in the first release I installed. Or was that Mozilla... Consequently, Firefox has now been uninstalled from over 300 employees machines. Why? Because this trifling bug doesn't allow employees to search within the textareas of our CMS or Intranet's blog. I wonder how many other hard-won customers have since turned back to IE because of this? Sadly, the same problem still exists in Mozilla and has done since 2002. At least here this bug has a 'normal' rating.

You can't be for real... Read the comments in this bug. Just use the retro find extension for firefox.

(In reply to comment #98) > You can't be for real... Read the comments in this bug. > Just use the retro find extension for firefox. Hi David, I'll add that to the heap of other terribly helpful replies people have become accustomed to receiving when posting otherwise useful indications of their grief on this forum. It's about as inciteful as shouting "1, 2, 3, 4 - I declare a flame war". I didn't come here for a slanging match but for a solution. Having to read through seventy-four replies before reaching post #75 and its proposed 'fix' is not something I, or many others in my position, have time for. The fact that this bug is still open would strongly suggest that it has not been resolved. Please attempt to take at least a step in another man's shoes before adding to the unhelpful list of replies found on this page. For the hundreds of other people out there who might have missed it, there is a plugin available here - http://s93731204.onlinehome.us/firefox/retrofind.html - which reverts (you heard me) the find bar in Firefox back to a working state. This is an unacceptable solution for my organsiation. Some might think a patch which actually corrects the problem while keeping th efunctionality of the new find bar would be a better proposition, yes?

Don't be an asshat... I guess you've learned to read the comments in bugzilla carefully before posting. Next time you'd better do proper testing before trying to sell a product to your org.'s exec comittee that doesn't meet the requirements. And if you want a patch, write one yourself.

>Having to read through seventy-four replies before reaching post #75 and its >proposed 'fix' is not something I, or many others in my position, have time for. I agree, but you should at least take the time to vote for that bug (I couldn't find your name in the vote list :-)

(In reply to comment #101) > but you should at least take the time to vote for that bug (I couldn't > find your name in the vote list :-) (In reply to comment #102) David, had you read and understood my first point you would have noticed that this problem DID NOT EXIST in the earlier version I had tested. Stop being such a ninny. Avoiding the obvious issue at stake here and continuing to post inflammatory and nugatory remarks can only be satisfying a need in you which others here don't share. Please don't make finding the only currently available solution to this bug harder to find by posting here again.

Collecting money to find someone to solve this bug I have watched this bug from the beginning and unfortunately it seems that having 181 votes doesnt automatically mean it gets fixed - frustrated users who tell about the problems they have with this bug, just get **** off. I am not happy with this, because I think we as the FF/mozilla-community have to take the user´s problems seriously. As I don´t know what else to do about this bug, I started a thread on Mozillazine, where I am collecting money for the person who finally fixes this bug. I started by donating 5 $ - if you´re also frustrated about this bug as I am, please add your amount to the following thread: http://forums.mozillazine.org/viewtopic.php?p=1651419#1651419

(In reply to Comments #98 and #99) The extensions is even worse than described. It *partially* replaces find-as-you-type. That is, if you specifically type CTRL-F, it brings up an old-style find dialog which can search textareas. However, if you use the "/" key, find-as-you-type is still invoked, but is now doubly buggy. Not only does it not find text in textareas, but CTRL-G / Find Next fail to work properly (they search for the last entered text in the Find Dialog). Ugh! This is clearly unworkable on any professional level. I'll reiterate my and others' previous statements about Firefox being unusable for a wide range of web apps that involve editing text: wikis, CMS systems, blogs, feedback forms, you name it. While I've tried to look at the code involved in the fix, it's convoluted beyond my abilities to fix, so I'll just add my plea that a regular contributor to the project recognize how absurd and painful this bug is, and make it a priority for the next release. Continuing to pretend that this is not a problem for "real people", or is easily worked around, is just a pitiful rationalization. Thanks, --kirby

Don't renominate -ed bugs for no apparent reason.

This bug is ultra-annoying when trying to edit a wikipedia article. Try sifting through it by hand and you'll get turned off real quick..

Just to let you know - I use IE/Opera for editing text on webpages. This is one of the reasons that my friend decided NOT to switch to firefox. As you guys already know, this ONE bug is very important when considering which browser to use. I think this bug should be the first to be fixed if you want people to remain loyal firefox users.

i tried it only works if you choose to highlight all button. than it works fine. but if you turn if off it does not highlight it. it does not show.

i tried it only works if you choose to highlight all button. than it works fine. but if you turn if off it does not highlight it. it does not show.

(In reply to comment #109) > i tried it only works if you choose to highlight all button. > than it works fine. but if you turn if off it does not highlight it. it does not > show. What is interesting is that if you put highlight all it does higjlight it, but it does not take you to the highlighted text.

Why not a blocker for 1.8b5?! It will be ridiculous to release a SECOND major release with broken features.

it does not work on the 1.0.7 release conditate

To fix this requires substantial changes to the find mechanism, and we're far too late in the 1.5 cycle to take on that much risk. That said, this is on the radar for 2.0 already and some discussion has taken place on how to best implement this code.

In my opinion it would be less risky to implement a "non-perfect code" than waiting for FF2.0 and risking that many FF users (especially companies) switch to other browsers (see comment #97). Even if this means that the release date will be delayed - user´s needs should have a higher priority than release cycles! A possible solution: let´s find a quick-fix for FF1.5 and do a complete redesign of the find-code in 2.0. We shouldn´t expect from FF users to live with this bug one more YEAR!

There has to be something done with this annoying bug; as Yuchao719 mentioned before some users aren't considering changing their every-day browser because of this bug. I've "lost" a potencial user too, so please: let's do something here...

I agree. This has to be fixed! I've actualy committed to give 15$ to whoever fixes this bug (http://forums.mozillazine.org/viewtopic.php?t=301358). It is really annoying for me as a blogger, and I'm sure I'm not the only blogger that feels that way. How can you say that we are too far into the 1.5 cycle to do anything about this? After all this bug was filed way back in 2004!

My vote alone may not contribute much - but this bug is extremely annoying. I would very much appreciate it fixed.

You may believe that this is an important bug that must be fixed but please do not bugspam with advocacy comments. They do not help and only serve to complicate an already long bug.

(In reply to comment #118) 1) Instead of just complaining about bugspamming, why not point to the proper place for user comments? 2) I like Firefox well enough to use it for most tasks despite this bug and despite the bug where it can't copy with formatting from webpages and paste into applications like Excel. However, for other people bugs like this are deal breakers. I do find it incredible that both bugs are still a problem.

(In reply to comment #119) > (In reply to comment #118) > 1) Instead of just complaining about bugspamming, why not point to the proper > place for user comments? http://forums.mozillazine.org/ That is a forum, this is a place for developers to discuss solutions in the code. Unless you're posting a patch or some new insight about the bug, it's usually best to refrain from commenting. I should probably not be commenting, but I want the bugspam to stop too. I'm afraid, from past experience, it looks like the advocacy and bugspam here has actuallt killed the bug. Realize that by annoying the developers, you are nailing this bug into the ground so it will never be fixed. You'll always be able to copy the text into Notepad and search there, or where ever you prefer. Personally, I find that a lot easier than using another browser, and I do it for a lot of other things too (like formatting, etc.) But that's just me. Still, I'd love to see this bug fixed as much as the next guy... but I hope that the developers are left to their own devices so it can be. I trust them to prioritize things. -[Unknown]

(In reply to comment #120) > I'm afraid, from past experience, it looks like the advocacy and bugspam here > has actuallt killed the bug. Realize that by annoying the developers, you are > nailing this bug into the ground so it will never be fixed. Well I won't say any more in this inappropriate place after this, but I can't resist saying that if the developers are going to get **** because their users complain about the product, they might as well go work for Microsoft.

"I'm afraid, from past experience, it looks like the advocacy and bugspam here has actuallt killed the bug. Realize that by annoying the developers, you are nailing this bug into the ground so it will never be fixed." I agree with that statement. If I was a firefox or mozilla developer I would have unsubscribed from this bug a long time ago. David Lauri: the large majority of these developers are not paid for their hard work on this browser, and so complicated bugs and new features can often take a long time to get integrated. At the same time, since they work for free, they also don't enjoy getting harrassed about unfixed bugs. Even more so, for un-implemented features. Patience is something that really comes in handy for faithful users of open source products. And never tell anyone what they should or shouldn't do in the OSS community especially if you are not a developer. You can suggest a new feature once in a nice, friendly way...otherwise, shutup, or do-it-yourself! Now I'm disassociating myself from this bug for good...I can't take the whining bugspam any longer.

Ok, this is sort of a workaround extension, it's like the retro find extension, but with this, the old find dialog only pops up when the textarea is focused: http://wargers.org/mozilla/oldfindtexarea.xpi Works with 1.5beta2 (not with 1.5beta1).

Tha bug was fixed in Epiphany. http://www.gnome.org/projects/epiphany/

(In reply to comment #124) WTF? We are talking about firefox

comment #125(In reply to comment #125) > (In reply to comment #124) > WTF? We are talking about firefox From http://www.gnome.org/projects/epiphany/ "Powered by the Gecko engine ..." The idea is probably to investigate if a backport is possible.

Gecko is a layout engine ( http://en.wikipedia.org/wiki/Gecko_%28layout_engine%29 ). This is filed under "Find Toolbar/FastFind", which suggests it's not tied to the layout engine at all.

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

I had this problem with all versions till 1.0.6. I uninstall all my extensions and it works again. Don't know which one causes the problem...

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

(In reply to comment #64) The WORKAROUND (comment #64 refers to) has moved to a new location: http://wargers.org/home.hccnet.nl/bookmarklets/searchtextarea.htm

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

My advice would be to re submit this, referencing this. It has been completely abused with posts which has put people of fixing it. If your not saying anything helpful then dont bother, thats only stopping it getting fixed.

(In reply to comment #133) > My advice would be to re submit this, referencing this. It has been completely > abused with posts which has put people of fixing it. If your not saying > anything helpful then dont bother, thats only stopping it getting fixed. Absolutely not. Filing duplicate bugs knowingly is just as bad, if not worse.

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

When selecting "highlight" on the find bar, it highlight it, but clicking on "find next"or "find previous" it does not find it. I have the same problem that Philipp Lenssen.

(In reply to comment #136) Same here highlight work but next or previous not. It an old bug, what can we do to get developers attention?

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

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

I'd like to have this fixed :-) Would be great! IE already does that!

(In reply to comment #140) How can SearchWP/SearchBox Sync do it but Firefox itself can't?? http://www.legege.com/mozilla/searchwp.php I've been using this as a workaround, but c'mon...

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

I recently upgraded to Firefox 1.5 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051129 Mandriva/1.5-0.1.20060mdk (2006.0) Firefox/1.5) and this new intra-page search problem developed. Previously, the intra-page search worked fine. Now, the find box says "undefined" and after adding a search term, none of the find next/findprevious/highlight all buttons work. Nothing happens. This is a major handicap!!!! If it's not fixed soon, I'll have to give up Firefox as my main browser.

(In reply to comment #143) Many people are already giving up firefox because of this bug and various other major ones that have remain unresolved for a year now. I know that the developers are working hard and I congratulate your well-spent free time and efforts. But the simple fact is - this bug is a major blow to firefox's reputation. Personally, I would like to see the major bugs resolved BEFORE the minor, aesthetic problems are even taken into account. I'd love to learn programming and help the development, but hey I'm just a high school kid trying to keep up marks in various honors courses, and other people have busy lives as well. Major bugs like this one come down to one question: Do we want people using (or to remain using) firefox or not?

(In reply to comment #144) Come on, giving up on Firefox because of a major bug might be justified, but as has been repeatedly mentioned on this thread (which incidentally is *not* the place to complain about the bug), you can dispense with the problem simply by installing this extension: http://s93731204.onlinehome.us/firefox/retrofind.html

(In reply to comment #145) > has been repeatedly mentioned on this thread (which incidentally is *not* the > place to complain about the bug), you can dispense with the problem simply by > installing this extension: > > http://s93731204.onlinehome.us/firefox/retrofind.html That's a poor, kludgy solution. I tried it for a while and had to uninstall it. Using SearchWP as a kludge workaround is better, but still not great.

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

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

idea: implement text box as DHTML component so the search in it will be HTML'ish and text input too.

(In reply to comment #149) > idea: > implement text box as DHTML component so the search in it will be HTML'ish I don't like it. too geeky. You can still search for html in page source. It wouldn't help users since every website writes their own strange style of html (<span style="font-weight:bold">, <strong>, <b>)

We're switching the blocking flags over to bug 189039.

OK, I'm duping this against bug 189039, where I've been doing the real work for this. As far as I know this bug is not different than that one, so this is now fixed on the trunk. *** This bug has been marked as a duplicate of 189039 ***

(In reply to comment #152) > OK, I'm duping this against bug 189039, where I've been doing the real work for > this. As far as I know this bug is not different than that one, so this is now > fixed on the trunk. Except THIS bug was a target of 2.0.

(In reply to comment #153) > Except THIS bug was a target of 2.0. So is that one (we've been flagging and driving these two bugs together for a while, this bug just wasn't duped earlier because I didn't want 300 people coming and visiting the non-spam-filled bug where I was doing real work). Anyway, our practice in bugzilla isn't to keep multiple bugs on the exact same item open just for distinct milestone targets. The fix is checked into the trunk, bakes until it is shown to be safe, and then gets merged back into whatever branches are appropriate. That isn't changing here. Firefox 2 will get this fix if and when it's shown to be safe enough on the trunk.

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

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