From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.3+) Gecko/20010816 Netscape6/6.1b1 BuildID: 20010816 Attempting search by null string does not return error message ``Nothing to search for.'' Reproducible: Always Steps to Reproduce: (1) Open a normal document in the editor (2) Enter a null string (_e.g.,_ " ") in the Find dialog Actual Results: Apparently nothing. Expected Results: Nothing would be found in a document, and an error dialog should pop up: "Nothing to search for". Continually clicking the [Find Next] button still apparently has no effect. Even attempted a multiple-space null string, with exactly the same results.

I opened a document I had with lists in it. I looked for a space. I did see the selection sometimes but sometimes I didn't. I then tried to replace the space character with an x. I see the x being put in places I wouldn't anticipate (6 before a sub-list item, about 20 after the sublist item, about 30 before the next sublist item and 30 more after the next item. There seems to be a bug here...who would like to investigate? :-)

No need to investigate, i know what the problem is. Our content tree contains the formatting spaces used in the HTML file. These formatting spaces don't render, but they are still in the content tree, so the find code finds them and selects them. Selection doesn't render any hiliting on things that don't have frames on the screen, so this is what causes it to appear and disappear. In your example, when you are replacing a ' ' with an 'x' you are getting an x everywhere there was a space in the file ... toggle to view source mode, I'll bet it's now unreadable. ;-)

In regards to this issue "searching for null string results with no error message", on Mac OS X, build 2001112608, when searching for a null string on a document in Composer, it actually returns the message "the text you entered was not found" and then brings up a seperate 'Find in this Page' dialogue box. Happens every time.

Akkana: I'm re-assigning this to you since Kin says you have been working on this issue.

Does this still happen? Completely new find code went in a few weeks ago, so please check and give me a test case if it's still happening, so I know whether this still needs action in the new code.

Incidentally, a space isn't a null string, and searching for a space should find a space. The QA test case has been updated to be clearer about that.

I believe the new find still has the same problem since it doesn't distinguish whitespace formatting nodes from real content. For example: <p> Paragraph Text </p> <p> Paragraph Text </p>

So *both* the find code and the copy code eventually need to have the nsWSRunObject thingy from editor pulled in.

Joe: if you're moving nsWSRunObject anyway, any chance it can be scriptable? I have code in EdReplace.js that mostly duplicates the whitespace-detection code in nsFind.cpp; if the interface could somehow be abstracted into a scriptable class then all these objects could call the same code.

I guess so. Nonoe of this will happen for moz1.0 anyway. After that we should get together and plan out what functionality the find code and the copy code need, and design the right interface. Then I'll do brain surgery on the whitespace code and put the juicy bits over where content and find can find them.

No word on the WSRunObject work. I filed bug 169319 to track the issue. Moving this to future until that bug is fixed or at least has a milestone.