Closed Bug 252371 Opened 20 years ago Closed 18 years ago

incremental find/search in page does not find/highlight text in textarea/form/edit/text entry boxes

Categories

(Toolkit :: Find Toolbar, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 189039
mozilla1.8.1beta1

People

(Reporter: jellis, Assigned: pkasting)

References

Details

(Keywords: helpwanted, regression, Whiteboard: [DO NOT comment unless you are contributing to a SOLUTION])

Attachments

(1 file)

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
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
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+
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Summary: find in page does not highlight text in textboxes → incremental find in page does not highlight text in text entry boxes
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Keywords: regression
Flags: blocking-aviary1.0PR?
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. ***
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR+
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?
Whiteboard: [eta: 8/17/2004]
Hardware: PC → All
> 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.
Depends on: 189039
For PR1, we're not going to find text in textboxes. Patch checked in. Moving to
1.0+.
Flags: blocking-aviary1.0PR+ → blocking-aviary1.0+
Whiteboard: [eta: 8/17/2004]
*** Bug 255286 has been marked as a duplicate of this bug. ***
QA Contact: ian
*** 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.
Summary: incremental find in page does not highlight text in text entry boxes → incremental find in page does not find/highlight text in textarea/form/text entry boxes
Not a "blocker"
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
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. ***
Flags: blocking-aviary1.0- → blocking-aviary1.0+
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. 
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
*** 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. ***
Summary: incremental find in page does not find/highlight text in textarea/form/text entry boxes → incremental find/search in page does not find/highlight text in textarea/form/text entry boxes
*** 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.
Keywords: helpwanted
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. ***
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1? → blocking-aviary1.1+
Resetting to ?1.1

I assume garbage accidentally plussed the bug
Flags: blocking-aviary1.1+ → blocking-aviary1.1?
(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!
Flags: blocking-aviary1.1? → blocking-aviary1.1+
garbage@loz.it:
Don't touch the bloacking flags, other than to request them (?).
Flags: blocking-aviary1.1+ → blocking-aviary1.1?
if we can get a patch please renominate. 
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Flags: blocking-aviary1.1- → blocking-aviary1.1?
garbage@loz.it: Please read comment 72 before you re-nominate.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
(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. ***
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1-
Flags: blocking-aviary1.0.4?
Flags: blocking-aviary1.0.3?
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.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
*** 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
Flags: blocking-aviary1.1- → blocking-aviary1.1?
(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).
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Flags: blocking-aviary1.0.3?
*** 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!!
Blocks: majorbugs
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.
Version: unspecified → Trunk
*** 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. ***
No longer blocks: majorbugs
Not in scope for a security release
Flags: blocking-aviary1.0.5? → blocking-aviary1.0.5-
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
Flags: blocking-aviary2.0?
(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
Whiteboard: [DO NOT comment unless you are contributing to a SOLUTION]
Flags: blocking-aviary1.5- → blocking-aviary1.5?
Don't renominate -ed bugs for no apparent reason.
Flags: blocking-aviary1.5?
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..
Assignee: firefox → nobody
Priority: P3 → --
QA Contact: ian → fast.find
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. 
Flags: blocking1.8b5?
Flags: blocking1.8b5? → blocking1.8b5-
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.
Flags: blocking-aviary2.0? → blocking-aviary2.0+
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.
Summary: incremental find/search in page does not find/highlight text in textarea/form/text entry boxes → incremental find/search in page does not find/highlight text in textarea/form/edit/text entry boxes
(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. ***
Target Milestone: --- → Firefox 2 beta1
Depends on: 263683
*** 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>)
Assignee: nobody → pkasting
No longer depends on: 263683
We're switching the blocking flags over to bug 189039.
Flags: blocking-firefox2+
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 ***
Status: NEW → RESOLVED
Closed: 20 years ago18 years ago
Resolution: --- → DUPLICATE
(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. ***
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: