Find/Search feature doesn't find text that is present in an XML document upon the first search.

REOPENED
Unassigned

Status

()

P5
normal
REOPENED
10 years ago
3 years ago

People

(Reporter: jonforeman, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

When I load an XML page and search for text within that page that i know exists, find will report initially that it doesn't exist. This is intermittent. 

If I delete the text and type it in again, Find will locate the text successfully within the XML document.

Reproducible: Always

Steps to Reproduce:
1. Load this URL http://api.npr.org/query?id=93274466&output=NPRML&numResults=2&apiKey=MDAxODM4NjUzMDEyMTcwMDM3OTFkMmFjYg001
2. Hit 'Control F'
3. Enter 'some text' that I know is present in the XML document in the 'Find:' toolbar. HOWEVER - the text is not found.
4. If I erase the text and type it in again, it typically finds the text in the XML document.
Actual Results:  
'Find' reported that the text I searched for wasn't available.

Expected Results:  
'Find' should have reported that the text I was searching for was present in the document.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

I was indeed able to reproduce this but not in a new profile, so maybe caused by an add-on or setting?
(Reporter)

Comment 2

10 years ago
I disabled all of my add ons. At first the search worked. But I tried some other xml urls and the problem came up again.

I don't see an option to restore all settings to defaults in Firefox...
Easiest is to test in a new profile. Close Firefox, click Start -> Run, type firefox -p and create an additional new profile.
I tested only the URL in comment 1 BTW.
(Reporter)

Comment 4

10 years ago
Thanks for the tip...

I ran firefox -p, created a new profile and duplicated the issue. Then I disabled the two extensions that came as a default in the new profile (google gears/google earth) and restarted. I was able to duplicate.

One thing I noticed:

This didn't happen all the time. The first searches I did worked fine. Also, the search ALWAYS worked if I loaded an xml document and clicked somewhere in the page before doing the search.

The search only seems to fail when loading the xml document, hitting control f and then typing in a search term. And it doesn't always fail under these circumstances. The first few searches worked.

For now I suppose the click is a work-around... just have to remember to do that.
Component: General → Find Toolbar
Product: Firefox → Toolkit
QA Contact: general → fast.find

Comment 5

10 years ago
It should also be noted that hitting Previous seems to never work. So search for text with multiple occurrences, use next to go to the second occurance, then hit previous and it will fail.

Comment 6

10 years ago
I have the same problem under WinXP/FF 3.0.7

Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.7) Gecko/2009021910
Firefox/3.0.7 (.NET CLR 3.5.30729)

This issue is similar to #408665

Comment 7

10 years ago
Could reproduce with:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.8) Gecko/2009032608 Firefox/3.0.8

Workaround is to do View > Page Source and search in the source.

Comment 8

10 years ago
It only misbehaves when you have searched at least once since starting Firefox.
I made a log with DEBUG_FIND enabled:
http://www.linuxonly.nl/docs/35/logging2.txt.gz
While searching for 'l' on this file:
http://www.linuxonly.nl/docs/35/sitemap_news.xml

Interesting part:
Comparing 'O'=4f to 'l' (0 of 0), findex=25
NOT: o == l
Setting findex back to 25, pindex to 0
Loop ...
Same node -- (0, 26)
Comparing 'L'=4c to 'l' (0 of 0), findex=26
YES! 'l' == 'l' (0 of 0)
Found a match!
NOT: l == l
Setting findex back to 26, pindex to 0
Loop ...

Comment 9

10 years ago
Debug output shows that when the search fails, nsTypeAheadFind::IsRangeVisible does not find a firstVisibleNode, thus mStartPointRange is not correctly initialized.

Comment 10

10 years ago
nsTypeAheadFind::IsRangeVisible exits before assigning firstVisibleNode because aMustBeInViewPort is false (nsTypeAheadFind.cpp:1127). Supplying PR_TRUE as third parameter instead of aIsFirstVisiblePreferred fixes this bug. I do not have enough understanding of the code to know for sure that this has any other consequences. However, as IsRangeVisible in this situation has the task of filling mStartPointRange, I think it is desirable that IsRangeVisible actually does that always, thus aMustBeInViewPort should be false.

Comment 11

10 years ago
Created attachment 373726 [details] [diff] [review]
Possible fix

Comment 12

10 years ago
Find previous still does not work correctly, but this is described in bug 263049.

Updated

10 years ago
Attachment #373726 - Flags: review?(mconnor)

Updated

10 years ago
Attachment #373726 - Flags: review?(mconnor) → review?(mano)

Comment 13

8 years ago
I have the same problem, I can't search at first load but if I either click on the page and then search or delete my search text and retype, it works.

thanks
nizam

Comment 14

8 years ago
I have a similar repro:
1. loaded a XML file of countries. There are 30 DE keywords in the XML
2. search for keywoard DE
3. Search finds the first to the last DE but the find Previous button can't find the previous DE. Shift+F3 does not find the previous DE either.

Comment 15

7 years ago
Fresh FF 7.0.1 on Windows.

I load an XML document. It displays. I press crtl F. I type an existing word. I incorrectly get "not found". I click in the document. I retry. Now the result is found. I press F3... I get the next results... After the last one, the search must loop, as it does usually. It doesn't. Instead, it says "not found". I even press crtl Beginning. I F3 again. I again get incorrectly "not found".

Comment 16

7 years ago
(In reply to Sjoerd from comment #12)
> Find previous still does not work correctly, but this is described in bug
> 263049.

reading comment #10 and #11, make sense , is your patch still not applied in firefox 11 ?
is not easy or quick recompile Firefox, but I could test it if worth it, you have test it ? since 2009

Comment 17

6 years ago
using 18.0.2 on a Mac

viewing an XML document, "view page source" "CMD-F - Quick Find", can find a value correctly ie: <id>4970385</id>. note: "view page source"

but on actual document rendered by FF18, ie: *not* view page source, Quick Find cannot find 4970385. exactly same behaviour as reported above.
(Reporter)

Comment 18

6 years ago
As far as I can tell this problem no longer exists in current versions of Firefox.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME

Updated

6 years ago
Duplicate of this bug: 408665
Still broken in today's nightly, though it does work better. Using the example linked from the first comment.

The search won't loop within the document. So once you've passed some text, you won't ever find it. In the document linked from the first post you can find 'teaser' 4 times then it stops being found.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WORKSFORME → ---

Updated

6 years ago
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk

Updated

6 years ago
Duplicate of this bug: 830640

Updated

6 years ago
Duplicate of this bug: 445978

Comment 23

6 years ago
this is a duplicated bug of #263049 , please fix it
20.0 win7 beta still doesn't work

Comment 25

5 years ago
Created attachment 782378 [details] [diff] [review]
bug449235.patch

I try this patch on firefox 22 and doesn't work , on xml finds
Duplicate of this bug: 911116

Comment 27

4 years ago
Still doesn't work on Firefox 30.0 on Win7

Comment 28

4 years ago
please mark this as duplicated of #263049 

there we have a patch that make some progresses

Updated

4 years ago
Duplicate of this bug: 1050844
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.