185824 - Type-ahead find fails with frames

Status: VERIFIED FIXED

(SeaMonkey :: Find In Page, defect)

Description

[brian]

Steps to reproduce:

1) Go to the URL: http://java.sun.com/j2se/1.4.1/docs/api/index.html. These are
the javadoc for j2se1.4.1.
2) Suppose we are looking for info on the class 'FileWriter'. So start typing
'filew'.
3) when we get to the 'w' type-ahead-find is only highlighting 'ileW'.

This might be due to jumping between frames.

Here's another repro case on the same URL:

1) same site.
2) suppose we're looking for the javax.xml packages. So start typing xml
3) 'x' matches 'java.beans.beanscontext' --> ok
   'xm' matches 'java.math' --> bug!
   'xml' matches 'javax.swing.text.html' --> bug!

Tested with 1.2.1.

Sorry, but i couldn't find a suitable component for type-ahead-find. please
reassign as appropriate.

Comment 1

[Matthias Versen [:Matti]]

.

Comment 2

[sairuh (rarely reading bugmail)]

i think this is resolved in more recent [trunk] builds, but i'll check in a bit.

Comment 3

[sairuh (rarely reading bugmail)]

actually the 2nd case above fails for me as well. in comparison, the Find in
this Page dialog does work. tested with 2002.12.16.08 comm trunk bits on linux rh8.

Comment 4

[dmorg]

This exists in Phoenix 0.5 (12/19/02 build) on Windows 2000 SP3, and Redhat 8.0

Comment 5

[Mike Gratton]

An irritating-to-use work-around for this bug is to select some text in the
frame which contains the match, then start typing your search.

For example, in the testcase Javadoc, select the text "Java" in the upper-left
frame, then type "xml". Note that it correctly matches "javax.xml.parsers".

Maybe that provides some insight into the actual problem? :) It would be
fantastic to get this bug fixed; this is a killer, utterly fantatsic, feature
for all Java developers out there, when it works.

The problem still exists in 1.3a on Linux.

Comment 6

[Frank Widmaier]

OK - other strange behavior [1].
The example (posting 1) works correctly - sometimes. (it will highlight "filew"
completely when working)
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030207

But mostly it only highlights /one/ charakter. Will I input "filew", I get first
marked, the first "f", then the next "i", then the next "l" and so on.

When I was testing now, I could find something like a pattern.
Will I load the site new and won't click on one of the pages - it works. Have I
clicked on one frame, it only highlights character for character. A reload won't
help - but if I change the tab and return to the tab with the example it will
work again until I click on one of the frames.

on de.comm.software.mozilla someone has given us the description of the new
problem I described. his example was:
http://www.zahlungsverkehrsfragen.de/frameset.html
it has the same problem: type ahead works, when you won't click on a frame

Comment 7

[Aaron Leventhal]

I believe these problems will be fixed when I check in the fix for bug 190555.

Comment 8

[Marius Strumyla]

works for me with
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030221

older build 20030210 used to have this bug.

Comment 9

[sairuh (rarely reading bugmail)]

marking w4m per previous comment --will check later to verify...

Comment 10

[:deanis74]

Verified wfm using today's Phoenix build.  It's the same code.

Comment 11

[Ari Savolainen]

Does not work for me with
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925

Comment 12

[Ari Savolainen]

Does not work for me with:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031029.

The problem is described many times in comments here but I give still another
example of steps to reproduce the bug. (In the linux version of 1.6a.)
1) Go to the URL: http://java.sun.com/j2se/1.4.1/docs/api/index.html.
2) Don't click any frames. The step 3 works only when no frame has the focus.
3) Type 'ja'. After 'j' the focus is on the first appearance of the word 'java'
(in the upper left frame), but after 'a' it is on the word 'All' a bit above.
4) Type esc to start a new type ahead find.
5) Type 'string'. Below is the list how the focus is jumping:
   's'      'All classes' (upper left frame)
   'st'     'java.rmi.registry' (upper left frame)
   'stri'   'AttributedString' (lower left frame)
   'string' 'java.lang' (upper left frame)
After writing the whole word string 'there' is text 'Link found: "ng"' in the
status bar. This behaviour is not consistent. Some times the focus is remained
on the word 'AttributedString' after typing the word 'string'. But when I click
the upper right frame right after loading the page and then type 'string' the
focus is always on the link with text 'java.lang'.

Comment 13

[Ari Savolainen]

In the previous comment the line after the fifth step should be:
After writing the whole word 'string' there is text 'Link found: "ng"' in the

Comment 14

[Aaron Leventhal]

Ari, I don't have time to work on this now, but than you for throughly
documenting the problem.

Comment 15

[Ari Savolainen]

This bug seems to be fixed in
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803

Comment 16

[sairuh (rarely reading bugmail)]

I'm not sure if the following would be covered under this bug. Aaron, let me
know if I should file another bug.

0. have FAYT (find as you type) set to find non-link as well as linked text.

1. go to a page with frames such as
http://java.sun.com/j2se/1.4.2/docs/api/index.html

2. place focus in a frame other than the upper-left frame --eg, the main
right-hand frame. click there or use F6 (or ctrl+tab on Mac) move focus there.

3. try to use FAYT find a *whole* word in the right-hand frame, such as "overview"

expected: "overview" in the right-hand frame should become highlighted.

actual results: the letters *one at a time* --"o", "v", "e", and so forth--
become highlighted in the upper-left frame.

that only the first frame is being search is likely bug 197246. however, would
this bug cover the oddness with only one char at time being highlighted?

this seems limited to trunk builds:

* Seamonkey (mozilla) trunk (tested all platforms, 20040817 bits)
* Firefox trunk builds also affected

this does not appear to be an issue using Firefox aviary1.0 branch builds (such
as today's bits).

Comment 17

[Ari Savolainen]

This bug reappeared in
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817

Comment 18

[Ari Savolainen]

This bug does not exist in
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040714
but reappeared in
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040817

Comment 19

[Aaron Leventhal]

Attachment: 1) Don't prefer first visible if frame/iframe already focused, 2) Make sure if search result in new doc, the new doc gets focused, 3) Some null checks for bug 255002

Comment 20

[Eliot Lear]

I've tested this patch; works fine; addresses problem listed in bug.

Comment 21

[Johnny Stenback (:jst)]

Comment on attachment 157362 [details] [diff] [review]
1) Don't prefer first visible if frame/iframe already focused, 2) Make sure if search result in new doc, the new doc gets focused, 3) Some null checks for bug 255002

sr=jst

Comment 22

[Aaron Leventhal]

Checking in nsTypeAheadFind.cpp;
/cvsroot/mozilla/extensions/typeaheadfind/src/nsTypeAheadFind.cpp,v  <-- 
nsTypeAheadFind.cpp
new revision: 1.98; previous revision: 1.97
done

Comment 23

[Aaron Leventhal]

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

Comment 24

[sairuh (rarely reading bugmail)]

looks good with current trunk builds. tested on Mac OS X 10.3.7,
20050110xx-trunk bits of Firefox and Mozilla. thanks for fixing this!

Comment 25

[Boris Zbarsky [:bzbarsky]]

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

Comment 26

[Boris Zbarsky [:bzbarsky]]

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

Comment 27

[Nickolay_Ponomarev]

bug 265002 claims that the change to mIsFirstVisiblePreferred caused a change in
behavior (search is now started from the beginning of the page, even if we
scrolled down first, - even in case there are no frames). Was that intentional
and if it was, what were the reasons for this change (in behavior).