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)
SeaMonkey
Find In Page
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.1final
People
(Reporter: tuukka.tolvanen, Assigned: aaronlev)
References
Details
Attachments
(3 files, 2 obsolete files)
424 bytes,
text/html
|
Details | |
4.32 KB,
text/html
|
Details | |
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
Assignee | ||
Comment 1•22 years ago
|
||
It looks like this is due to it finding text in comment nodes in the head
Assignee | ||
Updated•22 years ago
|
Status: UNCONFIRMED → ASSIGNED
Depends on: 166419
Ever confirmed: true
OS: Linux → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.1final
Assignee | ||
Comment 2•22 years ago
|
||
Comment 3•22 years ago
|
||
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.
Assignee | ||
Comment 4•22 years ago
|
||
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 5•22 years ago
|
||
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+
Because nsWebBrowser::GetRootNode calls GetBody? http://lxr.mozilla.org/mozilla/source/embedding/components/find/src/nsWebBrowserFind.cpp#319
Comment 8•22 years ago
|
||
Thanks, Dean. For some reason I was missing that ... duh.
Comment 9•22 years ago
|
||
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 10•22 years ago
|
||
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+
Assignee | ||
Comment 11•22 years ago
|
||
Boris, I filed a bug to fix nsFind - bug 166471.
Assignee | ||
Comment 12•22 years ago
|
||
checked in
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 13•22 years ago
|
||
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.
Assignee | ||
Comment 14•22 years ago
|
||
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.
Comment 15•22 years ago
|
||
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.
Assignee | ||
Comment 16•22 years ago
|
||
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.
Comment 17•22 years ago
|
||
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).
Assignee | ||
Comment 18•22 years ago
|
||
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 → ---
Assignee | ||
Comment 19•22 years ago
|
||
Comment 21•22 years ago
|
||
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 22•22 years ago
|
||
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+
Comment 23•22 years ago
|
||
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.
Comment 24•22 years ago
|
||
Found it - bug 171260
Assignee | ||
Comment 25•21 years ago
|
||
Forgot to mark this one fixed.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
Comment 26•21 years ago
|
||
works fine --tested with 2003.05.23.0x comm trunk builds.
Status: RESOLVED → VERIFIED
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•