Closed Bug 78833 Opened 23 years ago Closed 18 years ago

find in page does not scroll selection to correct screen position

Categories

(SeaMonkey :: UI Design, defect, P4)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 171237
Milestone:
Future

People

(Reporter: zackw, Assigned: kinmoz)

References

(
URL
)

Details

Attachments

(1 file)

Changes interface for ScrollSelectionIntoView in a number of places
9.11 KB, patch
Details | Diff | Splinter Review 
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 "
Assignee: asa → matt
Status: UNCONFIRMED → NEW
Component: Browser-General → Search
Ever confirmed: true
QA Contact: doronr → claudius
Summary: Search puts string searched for at bottom of screen → find in page does not scroll selection to correct screen position
This is kin's stuff.
Assignee: matt → kin
moving this out to 1.0
Severity: normal → minor
Priority: -- → P4
Target Milestone: --- → mozilla1.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.
URL: http://developer.apple.com/techpubs/m...
Blocks: 106961
Component: Search → XP Apps: GUI Features
QA Contact: claudius → sairuh
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.
Target Milestone: mozilla1.0 → mozilla1.0.1
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".
QA Contact: sairuh → pmac
*** 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.
Target Milestone: mozilla1.0.1 → Future
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.
QA Contact: pmac → sairuh
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. ***
Product: Core → Mozilla Application Suite
*** 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 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.