Closed Bug 166340 Opened 22 years ago Closed 21 years ago

type ahead find on full text won't find some characters

Categories

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

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.1final

People

(Reporter: tuukka.tolvanen, Assigned: aaronlev)

References

Details

Attachments

(3 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020902
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020902

For me typeaheadfind won't find any of (at least) abgiloruz1 as the first
character, in full search mode.

see bug 30088 comment 196

Reproducible: Always

Steps to Reproduce:
I:  1. user_pref("accessibility.typeaheadfind", true);
    2. user_pref("accessibility.typeaheadfind.linksonly", false);
    3. say branch

II: 1. user_pref("accessibility.typeaheadfind", true);
    2. user_pref("accessibility.typeaheadfind.linksonly", true);
    3. say 'branch

Actual Results:  
not finding 'b', 'r', 'a'; hilight nch

Expected Results:  
find & hilight branch

linux trunk cvs 2002-09-02
Blocks: isearch
It looks like this is due to it finding text in comment nodes in the head
Status: UNCONFIRMED → ASSIGNED
Depends on: 166419
Ever confirmed: true
OS: Linux → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.1final
Attached file Test case
Here's a test case that loads a lot faster than a bugzilla page.

It turns out that the offending comment isn't in the head either; it comes
before even the <html> tag.

I don't understand at this point why typeahead find has this problem and
regular find doesn't.
The fix is based on GetBody() now. We're also saving ourselves from getting the
doc selection when we don't need to now.
Attachment #97649 - Attachment is obsolete: true
Comment on attachment 97658 [details] [diff] [review]
Remove superfluous changes that still worked fine. 

r=akkana, looks fine.

Though I still wish we understood why regular find doesn't have this problem.
Attachment #97658 - Flags: review+
s/nsWebBrowser/nsWebBrowserFind
Thanks, Dean.  For some reason I was missing that ... duh.
So... I don't like this approach, here or in regular Find.  This is _especially_
so because there will come a time when we'll make XHTML work and create an
HTMLDocument... This is ok as a stopgap measure for now, I guess, but I should
be able to do:

head, title { display: block }

in my HTML document's stylesheet and not only see the <title> contents rendered
(as I do if I do this right this minute) but also be able to search them....
Comment on attachment 97658 [details] [diff] [review]
Remove superfluous changes that still worked fine. 

sr=bzbarsky, but let's keep this open for the real fix (or at least open a new
bug on that)
Attachment #97658 - Flags: superreview+
Boris, I filed a bug to fix nsFind - bug 166471.
checked in
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
hrm, for some reason i still cannot find the string "branch" in this page (in
comment 0) when on full text search. tested with 2002.09.26.04 moz trunk.

steps:
1. load this page (duh ;), and have focus near the top (just to be sure).
2. hit the / key (i'm in the default links-only mode).
3. start typing: b r a n c h

results:
after "b" and "r" the "Br" in comment 6 is highlighted.
after i hit "a", the status says 'Text not found "bra"'.
after i hit "n", the status says 'Text not found "brn"'.
after i hit "c", the status says 'Text not found "brc"'.
after i hit "h", the status says 'Type ahead find stopped'.

am i typing too fast? or is dependent on where focus was previously --even if
it's near the top of the page? another bug?

btw, i don't seem to encounter this with the simple attached test case.
I'm seeing that problem too, sort of.

It is finding the word b-r-a-n-c-h in your comment se -- it seems to be skipping
that word in comment 0, until I use Accel+G and have it wrap around.
I see this as well.  And when did Accel+G start wrapping around??  That never
used to happen and it should respect whatever I have set in my Find dialog.
Type ahead find always wraps around, that's how it's designed. That way when
you're at the bottom, and you start typing, you'll find something no matter
where it is. I Other people have told me that they want it that way. I think the
find-next/find-prev commands for typeaheadfind should stay consistent wrt
wraparound with typing for typeaheadfind use.
i guess i don't understand why b-r-a-n-c-h in comment 0 is not being found if
focus is initially near the top of this page (eg, clicked right below the
mozilla banner).
Aha, this apparantely has something to do with the large <pre> element that
wraps all of the bugzilla comments - I need a better algorithm to find the first
visible element on the page.

In any case, this regressed with some other stuff I did - but at least it's not
occuring on most pages, afaik.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment on attachment 100841 [details] [diff] [review]
Makes sure we start at selection when we're supposed to, and makes sure we test correct continuing text frames in visibility checks (instead of dumb primary frame check)

r=kyle
Attachment #100841 - Flags: review+
Comment on attachment 100841 [details] [diff] [review]
Makes sure we start at selection when we're supposed to, and makes sure we test correct continuing text frames in visibility checks (instead of dumb primary frame check)

sr=alecf
Attachment #100841 - Flags: superreview+
Aaron: OK, wrapping for typeahead kinda makes sense, I guess.  I'm sure, though,
that I ran into a situation where it was wrapping for me after a normal search,
thus my question.  If I can reproduce it I'll file a bug.
Found it - bug 171260
Component: Keyboard: Navigation → Keyboard: Find as you Type
Forgot to mark this one fixed.
Status: REOPENED → RESOLVED
Closed: 22 years ago21 years ago
Resolution: --- → FIXED
works fine --tested with 2003.05.23.0x comm trunk builds.
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: