Closed Bug 166340 Opened 22 years ago Closed 22 years ago

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

Categories

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

Product:
SeaMonkey
Component:
Find In Page
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.1final

People

(Reporter: tuukka.tolvanen, Assigned: aaronlev)

References

Details

Attachments

(3 files, 2 obsolete files)

Test case
424 bytes, text/html
Details
New test case, big para followed by small para. If you scroll down, and type "a" it should find the first visible "a"
4.32 KB, text/html
Details
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)
2.36 KB, patch
yuanyi21
: review+
alecf
: superreview+
Details | Diff | Splinter Review
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 ago → 22 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

Creator:
Created:
Updated:
Size: