reassigned to SBA.

confirming with 1.1.4 official linux build, setting to NEW

SBA: Same in 680m66 (OOo 1.9.65)
Personally, I do not like the jumping-around dialog in Word because repeatedly
hitting "Find next" forces the user to "hunt" the moving dialog.

Workaround (Works for Writer and Word alike! :-) is to shift the dialog to the
side and use the respective accelerators for "Find Next" (because in most cases
the dialog has to be moved out of the screen view). Then the dialog doesn't move
in Word and doesn't hide in Writer.

I can imagine a solution where the dialog jumps ONCE (i.e. to the top rmiddle or
right of the doc view) and thereafter only the document scrolls to show the "hits".

SBA->FME: I guess we have already talked about this. Smells a little like an
enhancement. Please give a statement, thank you.
Reassigned to FME.

This is part of a general problem with many OOo dialogs: they are all
unnecessarily large. Having >50% of the workspace covered by the find dialog is
very poor design.

OOo need a full audit of all dialog design to streamline/shrink them.

Another example is the Custom Animations dialog in Impress. When you select an
animation effect, an automatic preview is played. Unfortunately, with a few
docked windows, the previewed animation is 100% obscured by the Effects dialog.

I agree that "jumping around" dialogs is not the correct solution: dialogs
should stay where they are put. In the case of the Find&Replace dialog, a docked
panel (maybe at the bottom) would be the appropriate solution since, by
definition, the user will want the see the text highlighted by the
find-operation thus *no* part of the work-area should be covered. In this case,
instead of the dialog/panel moving to reveal the highlighted text, the document
can then be scrolled/panned instead.

Yes Bryan, exactly.  

I was thinking a text entry widget embedded in the right end of the bottom
button panel (attached to the bottom of the screen) would be good.  Care would
have to be taken with how to show the replace field, either also embedded
permanently (which takes up too much screen real estate) or better yet, increase
the height of the bottom bar with a single keystroke to show more options. 
Similar to blender, if I remember correctly. 

I can use find in vim or xemacs easily with one or two keystrokes, and it is
instantly useable with history (return, up-arrow) and incremental search as you
type.  There is no reason OOo should copy a bad part of MS Word, be slow (on my
system anyway) and perennially in the way or trying to get out of the way.

Would you like to write an enhancement request?

Yes Bryan, exactly.  

I was thinking a text entry widget embedded in the right end of the bottom
button panel (attached to the bottom of the screen) would be good.  Care would
have to be taken with how to show the replace field, either also embedded
permanently (which takes up too much screen real estate) or better yet, increase
the height of the bottom bar with a single keystroke to show more options. 
Similar to blender, if I remember correctly. 

I can use find in vim or xemacs easily with one or two keystrokes, and it is
instantly useable with history (return, up-arrow) and incremental search as you
type.  There is no reason OOo should copy a bad part of MS Word, be slow (on my
system anyway) and perennially in the way or trying to get out of the way.

Would you like to write an enhancement request?

By the way I have temporarily stopped replying to the bugs I submitted in order
to install the latest snapshot (which I have done) and go through all the issues
again (not yet).  I will be away from 12/25 to 1/5 though able to read email. 

*** Issue 95252 has been marked as a duplicate of this issue. ***

Further ideas:
(1) The hint in issue 37586 told about current Firefox version (8.x.x.x) where
the search box is always at the 
(2)Similar, but more flexible: Being able to dock the dialog, like the Navigator
or Styles & Formatting dialogs.