168018 - Typeaheadfind slow when started at bottom of long page

Status: VERIFIED FIXED

(SeaMonkey :: Find In Page, defect, P1)

Description

[Aaron Leventhal]

Go to the bottom of a fairly long page; for example, a long lxr source listing.
Press a letter and wait.

This used to be quick as lightning - it got broken along the way.

Comment 1

[Aaron Leventhal]

Attachment: The first frame (body's frame) was being reported as visible instead of above view port. We really need to start with the first visible leaf frame

Also fixes 2 other problems
- typeaheadfind wouldn't correclty start at selection or focus
- typeaheadfind selection wouldn't return to normal color after Ctrl+G used

Seeking r=/sr=

Comment 2

[Kyle Yuan]

Comment on attachment 98751 [details] [diff] [review]
The first frame (body's frame) was being reported as visible instead of above view port. We really need to start with the first visible leaf frame

r=kyle. okay with me, just one thing:
+    // We need to set the start point this way, other methods haven't worked
+    mStartPointRange->SelectNode(startNode);
+    mStartPointRange->SetStart(startNode, startOffset);
+    mStartPointRange->Collapse(PR_TRUE); // collapse to start
SetStart only works when the new start offset < current end offset. I do that
in my code like this:
  PRInt32 oldEndOffset;
  range->GetEndOffset(&oldEndOffset);
  if (aOffset < oldEndOffset) {
    range->SetStart(textNode, aOffset);
    range->Collapse(PR_TRUE);
  }
  else {
    range->SetEnd(textNode, aOffset);
    range->Collapse(PR_FALSE);
  }

Comment 3

[Alec Flett]

Comment on attachment 98751 [details] [diff] [review]
The first frame (body's frame) was being reported as visible instead of above view port. We really need to start with the first visible leaf frame

sr=alecf

Comment 4

[Aaron Leventhal]

checked in

Comment 5

[sairuh (rarely reading bugmail)]

tested by searching for the "LXR" at the bottom of this page (after waiting for
it to load, o'course ;).

http://lxr.mozilla.org/seamonkey/source/layout/html/style/src/nsCSSFrameConstructor.cpp

using 2002.09.24.08 mozilla trunk builds, these are the timed results i got per
platform (stopwatch, so a bit rough):

linux rh7.2 (500mhz, p3, 256mb ram) - 6.20sec
win2k (500mhz, p3, 128mb ram) - 4.25sec
mac os 10.1.5 (450mhz G3, 384mb ram) - 4.50sec

do these times sound reasonable for their respective configurations?

vrfy'ing as fixed, but reopen if the times are too slow.