Closed
Bug 336279
Opened 19 years ago
Closed 18 years ago
Find misses text in this testcase
Categories
(Toolkit :: Find Toolbar, defect)
Toolkit
Find Toolbar
Tracking
()
VERIFIED
FIXED
People
(Reporter: andrew.neitsch, Assigned: martijn.martijn)
References
()
Details
(Keywords: testcase)
Attachments
(4 files, 2 obsolete files)
51 bytes,
text/html
|
Details | |
95 bytes,
text/html
|
Details | |
4.21 KB,
text/plain
|
Details | |
1.53 KB,
patch
|
jst
:
review+
rbs
:
superreview+
|
Details | Diff | Splinter Review |
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.
Updated•19 years ago
|
Component: Keyboard Navigation → Find Toolbar / FastFind
QA Contact: keyboard.navigation → fast.find
Updated•19 years ago
|
Component: Find Toolbar / FastFind → Keyboard Navigation
Comment 1•19 years ago
|
||
That change was unintended.
Component: Keyboard Navigation → Find Toolbar / FastFind
Comment 2•19 years ago
|
||
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
Comment 3•19 years ago
|
||
Trying to find "yyy of zzz" in this testcase fails.
Comment 4•19 years ago
|
||
Attachment #220601 -
Attachment is obsolete: true
Comment 5•19 years ago
|
||
Attachment #220603 -
Attachment is obsolete: true
Updated•19 years ago
|
Summary: Find misses text in list item in this testcase → Find misses text in this testcase
Updated•19 years ago
|
OS: Windows XP → All
Hardware: PC → All
Comment 6•19 years ago
|
||
Masayuki, are you interested in fixing this or do you know who might be?
Comment 7•18 years ago
|
||
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).
Assignee | ||
Comment 9•18 years ago
|
||
Search for "a c"
Assignee | ||
Comment 10•18 years ago
|
||
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.
Assignee | ||
Comment 11•18 years ago
|
||
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)
Updated•18 years ago
|
Attachment #252516 -
Flags: review?(jst) → review+
Assignee | ||
Updated•18 years ago
|
Attachment #252516 -
Flags: superreview?(rbs)
Comment 12•18 years ago
|
||
Comment on attachment 252516 [details] [diff] [review]
patch
sr=rbs
Attachment #252516 -
Flags: superreview?(rbs) → superreview+
Assignee | ||
Updated•18 years ago
|
Assignee: nobody → martijn.martijn
Assignee | ||
Comment 13•18 years ago
|
||
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
Comment 14•18 years ago
|
||
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.
Assignee | ||
Comment 15•18 years ago
|
||
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.
Comment 16•18 years ago
|
||
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
Assignee | ||
Comment 17•18 years ago
|
||
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.
Comment 18•18 years ago
|
||
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.
Assignee | ||
Comment 19•18 years ago
|
||
I guess you could file a new bug for it.
Comment 21•17 years ago
|
||
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
Updated•17 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•