Closed Bug 336279 Opened 19 years ago Closed 18 years ago

Find misses text in this testcase

Categories

(Toolkit :: Find Toolbar, defect)

defect
Not set
major

Tracking

()

VERIFIED FIXED

People

(Reporter: andrew.neitsch, Assigned: martijn.martijn)

References

()

Details

(Keywords: testcase)

Attachments

(4 files, 2 obsolete files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2 Typeahead find gives a "Phrase not found" error for phrases which are clearly visible on the page. There is nothing unusual about the raw HTML, and the typeahead find of the phrase works for this page in the "view source" window. Reproducible: Always Steps to Reproduce: 1. Go to http://www.emerson.emory.edu/services/perl/perldoc/manual/index.html 2. Type "/hashes of hashes" Actual Results: As you type, "hashes of " on "hashes of list" gets selected, and when you press the next 'h', "Phrase not found" appears. Expected Results: The phrase "hashes of hashes" four lines below should get highlighted.
Component: Keyboard Navigation → Find Toolbar / FastFind
QA Contact: keyboard.navigation → fast.find
Component: Find Toolbar / FastFind → Keyboard Navigation
That change was unintended.
Component: Keyboard Navigation → Find Toolbar / FastFind
Confirmed using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060501 Minefield/3.0a1.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Summary: Typeahead find doesn't → Find misses text in list item in this testcase
Attached file testcase (obsolete) —
Trying to find "yyy of zzz" in this testcase fails.
Attached file clearer testcase (obsolete) —
Attachment #220601 - Attachment is obsolete: true
Attached file even clearer testcase
Attachment #220603 - Attachment is obsolete: true
Summary: Find misses text in list item in this testcase → Find misses text in this testcase
OS: Windows XP → All
Hardware: PC → All
Masayuki, are you interested in fixing this or do you know who might be?
This is still broken in the current version (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7).
Search for "a c"
This part is weird: Comparing 'a'=61 to 'a' (0 of 2), findex=0 (inWhitespace) NOT: a == It should not be possible that the result is 'NOT:' in this case, because the comparing just gave identical results. So something moved the index.
Attached patch patchSplinter Review
This fixes it for me. inWhitespace wasn't set back to false when the find code moves to a different block. This part: + if (textContent && textContent->IsNodeOfType(nsINode::eTEXT)) is just to fix annoying assertions and only happens when DEBUG_FIND=1.
Attachment #252516 - Flags: review?(jst)
Attachment #252516 - Flags: review?(jst) → review+
Attachment #252516 - Flags: superreview?(rbs)
Comment on attachment 252516 [details] [diff] [review] patch sr=rbs
Attachment #252516 - Flags: superreview?(rbs) → superreview+
Assignee: nobody → martijn.martijn
Checking in nsFind.cpp; /cvsroot/mozilla/embedding/components/find/src/nsFind.cpp,v <-- nsFind.cpp new revision: 1.42; previous revision: 1.41 done Checked into trunk.
Status: NEW → RESOLVED
Closed: 18 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
I wonder about "even more simpler testcase" in this bug (although it happens in other ones too) - Finding "a c" works fine after applying the patch, but when you type "a " ("a" and then press space) - "a " isn't highlighted in the text in the second line (it should be found too, right?). I'm using 2007013104 trunk on Windows.
It works for me, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070131 Minefield/3.0a2pre Could you provide exact steps to reproduce? Thanks.
Steps to reproduce: 1. Open the test case named "even more simpler testcase" from above 2. Press "a" - now "a" in the first line is highlighted - OK 3. Press space - "a" in the first line stays highlighted - which is not OK - "a " in the second line should be highlighted now, because it fits the search pattern
Ah, ok, that's what you mean. Well, the white-space after the "a" (which is a return) is considered a space for the find code. In html in general, returns are rendered as a white space.
Yeah, that's what I thought. Minor issue, but still, it may be a little confusing and unintuitive from user's point of view after all.
I guess you could file a new bug for it.
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042106 Minefield/3.0pre.
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: