171260 - typeahead find in a page with frames wrecks normal find

Status: VERIFIED FIXED

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

Description

[:deanis74]

1. Go to a page with frames (eg. www.generalcofee.com)
2. Type-ahead find for something simple that appears more than once in the page,
like 'e' (I search all text by default).
3. Ctrl+F
4. Type in junk (eg. 'asdasdaasd')
5. Hit Find

Expected Results: junk text not found

Actual Results: next occurrance of 'e' is found

Comment 1

[Aaron Leventhal]

Ugh, that's wrong.

Taking.

Comment 2

[:deanis74]

I've got 2002082508 at home and it doesn't seem to exhibit this behavior.  I
notice with this build that the typeahead find stops as soon as the find dialog
opens.  With the build from sept 27 that exhibits this bug, the typeahead find
stays active and times out normally after the dialog displays.

Comment 3

[Aaron Leventhal]

This bug, and bug 171079 are both regressions from my checkin to bug 167921. I
changed the way typeaheadfind detects where a nsIWebBrowserFind::FindNext() is
for normal find or for typeaheadfind. That check isn't working correctly (the
broken code is in nsTypeAheadFind::FindNext)

Comment 4

[:deanis74]

So is the call to GetWebBrowserFind failing, so typeaheadfind doesn't see the
Find dialog?

Comment 5

[Aaron Leventhal]

No, I don't think so -- but I'll have to investigate more.

Comment 6

[Aaron Leventhal]

This was fixed with the checkin to bug 168281.

Comment 7

[sairuh (rarely reading bugmail)]

tested on win2k and linux rh7.2 with 2002.10.22.08 comm trunk builds.

i think this still might be broken.

the orginal test case works fine, but i modified it a bit: after step 2, i did
find again using F3 (somehow accel-G doesn't exhibit this). then, after
following the remaining steps, the Find dlg still found 'e', rather than
returning an error for junk text not found.

should this be reopened, or should i spin off another bug?

Comment 8

[Aaron Leventhal]

Yeah, there still is a bug here.

nsTypeAheadFind::FindNext() is supposed to see there's a new different find
string, but it still sees the old one.

Comment 9

[Aaron Leventhal]

Attachment: Get the correct window to and get the nsIWebBrowserFind from that, for comparing the find strings

Seeking r=akkana, sr=sfraser

Comment 10

[Aaron Leventhal]

Attachment: Only change nsWebBrowserFind. The correct changes for nstypeaheadfind.cpp are in bug 175321

Comment 11

[Akkana Peck]

Comment on attachment 104539 [details] [diff] [review]
Only change nsWebBrowserFind. The correct changes for nstypeaheadfind.cpp are in bug 175321

r=akkana

Comment 12

[Simon Fraser [no longer active]]

Comment on attachment 104539 [details] [diff] [review]
Only change nsWebBrowserFind. The correct changes for nstypeaheadfind.cpp are in bug 175321

sr=sfraser

Comment 13

[Asa Dotzler [:asa]]

Comment on attachment 104539 [details] [diff] [review]
Only change nsWebBrowserFind. The correct changes for nstypeaheadfind.cpp are in bug 175321

a=asa for checkin to 1.2 (on behalf of drivers)

Comment 14

[Aaron Leventhal]

checked in

Comment 15

[sairuh (rarely reading bugmail)]

vrfy'd fixed, with both tests in comment 0 and comment 7. tested with 2002.11.19
comm trunk bits.

Comment 16

[:deanis74]

I think there was an error in this patch, carried over from copying the existing
code.

+    nsCOMPtr<nsIDOMWindow> rootFrame = do_QueryReferent(mRootSearchFrame);
+    NS_ENSURE_TRUE(searchFrame, NS_ERROR_NOT_INITIALIZED);

Shouldn't this be NS_ENSURE_TRUE(rootFrame, ...);

Comment 17

[:deanis74]

This typo's still there.  Aaron, it should be rootFrame instead of searchFrame.