The Search box puts the string you searched for at the bottom of the screen. This forces you to page down in order to see text after it. Netscape 4.x put the string at the top of the screen, which is much better although still not ideal. Four or five lines from the top would be best in my opinion.

please take a look at the bug writing guidelines to see the kind of information we need in a bug report. Thanks. http://www.mozilla.org/quality/bug-writing-guidelines.html

I had thought the original description was quite clear enough, but here's a play-by-play: - Load any web page with more than one screenful of text. Ideally, it should be very long. - Search ("Find in This Page") for any string which does not appear in the first screenful, but does somewhere in the page. - Mozilla will scroll just far enough that the string you searched for appears at the bottom of the screen. This is wrong. It should put it near, but not at, the top.

Zack, thanks for the followup. This description is much clearer. Updating summary and reassigning to the appropriate component. Adding mpt and german for UE input. Old summary was " Search puts string searched for at bottom of screen " new summary is " find in page does not scroll selection to correct screen position "

This is kin's stuff.

moving this out to 1.0

Whenever your application scrolls a document automatically, avoid unnecessary scrolling. Users want to control the position of documents, so your application should move a document only as much as necessary ... When you can show context on either side of a selection, it's useful to do so. It's also better to position a selection somewhere near the middle of a window than right up against a corner. I think the following algorithm would be the usability-maximizing one: (1) if the found text is contained within the viewport, don't scroll at all; (2) if it is possible to scroll less than a screenful in order to show the found text, scroll the minimum amount necessary; (3) failing either of those (so we have no chance to provide context), scroll so that the visual middle of the found text is as close to the middle of the viewport as possible.

akkana, d'you want this Find bug?

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

My new find stuff is calling mSelCon->ScrollSelectionIntoView, just like Kin's code was. The find code shouldn't need to do more than that; this is really a selection controller problem, not a find problem. What we really should do is enhance ScrollSelectionIntoView to be smarter. Personally, I'd expect to see found text near the top of the screen, not near the middle, but if mpt feels strongly about it going to the middle I wouldn't fight about it. SelectionController should perhaps allow for different options, e.g. top, middle, and bottom, in case different clients want to do different things -- e.g. an editor might want to put the selection in a different place from Find in page. But just putting it somewhere other than the bottom would be a good start.

Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these back in if I can.

Yeah, I prefer near the top myself. I think it's even more important to give context on both sides of the selection, though; unless the selection is the very first or last line of a page, Mozilla shouldn't put it at the very top or bottom of the screen.

mass moving open bugs pertaining to find in page/frame to pmac@netscape.com as qa contact. to find all bugspam pertaining to this, set your search string to "AppleSpongeCakeWithCaramelFrosting".

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

I also prefer scrolling so the found text is near the top or bottom. If we scroll to the middle or make it depend on how far the text is from the old viewport, it will take longer to spot the found text, and the Find dialog will get in the way more often (bug 87944). One nice thing about scrolling so that the found text is near the bottom is that is the text is always at the bottom of the viewport, even if the pattern appears in every paragraph. This would break for both top and middle, since the next occurrence of the pattern would often already be on the page.

Would it be too much to ask to move the find dialog when it obscures the word sougth? You can test need for this by searching for something that is on the first or last line on the page. For insance the word Log [in|out] is on the last line. Open fing dialog move it to the position the text would be in if visible. Enter string 'Log'. Press find and see the dialog obscure the text. A solution could be that the dialog is moved up/down so that the text is visible. Up or down could be decided on the basis of relative position to midpoint of the frame being sought in.

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

Opened bug 159402. This is related to comment 15 but not a duplicate, since it deals with situations in which the page cannot be scrolled.

Two considerations: 1. The found text should be positioned such that the user can view the context in which it is embedded. Thus, it might be NEAR the top or bottom of the page but not exactly at the top or bottom edge. Right-left scrolling might best position the found text near the top-center or bottom-center. 2. On a find-again (e.g., F3 or Ctrl-G on a PC), it is very handy to see where the next instance of the string is relative to the previous. If the previous found text were positioned near the top of the page (near the bottom when finding backwards), a nearby next instance could be found without any scrolling at all, thereby leaving the prior instance still visible.

FWIW, I "fixed" this by making the following change to the return value of the method of an nsTypedSelection named 'ScrollIntoView' in content/base/src/nsSelection.cpp (line 7583 in the Firefox 0.8 release) from this:: result = ScrollRectIntoView(scrollableView, rect, NS_PRESSHELL_SCROLL_ANYWHERE, NS_PRESSHELL_SCROLL_ANYWHERE, PR_TRUE); Into this:: result = ScrollRectIntoView(scrollableView, rect, NS_PRESSHELL_SCROLL_CENTER, NS_PRESSHELL_SCROLL_ANYWHERE, PR_TRUE); This will cause the find machinery (and lots of other machinery) to scroll the selection to the vertical center of the page, rather than scrolling only enough to display the selection at the bottom of the window. This is not the right fix, really, as ScrollIntoView is used for things other tham Find, but as a quick fix it's quite satisfatory.

This is a slightly better fix, although the change of interface might be hard to swallow. This patch (made against the HEAD as of today) causes the ScrollSelectionIntoView method to accept optional vertical and horizontal percentage values. Find and TypeAheadFind set the vertical percentage to NS_PRESSHELL_SCROLL_CENTER, while other things (like the editing machinery) default to NS_PRESSHELL_SCROLL_ANYWHERE, which preserves existing behavior for those places. Works for me, anyway.

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

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

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

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

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

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

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

duping to a new bug because it's ASSIGNED and it has better bug description *** This bug has been marked as a duplicate of 171237 ***