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

Status: REOPENED

(Toolkit :: Find Toolbar, defect, P5)

Description

[Jon Foreman]

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.

Comment 1

[Ria Klaassen (not reading all bugmail)]

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?

Comment 2

[Jon Foreman]

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...

Comment 3

[Ria Klaassen (not reading all bugmail)]

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.

Comment 4

[Jon Foreman]

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.

Comment 5

[Will Roberts [:bws42]]

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

[Beb]

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

[Sjoerd]

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

[Sjoerd]

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

[Sjoerd]

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

Comment 10

[Sjoerd]

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

[Sjoerd]

Attachment: Possible fix

Comment 12

[Sjoerd]

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

Comment 13

[Nizzy]

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

[Hil Liao]

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

[Nicolas Barbulesco]

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

[Sergio Basto]

(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

[Dan]

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.

Comment 18

[Jon Foreman]

As far as I can tell this problem no longer exists in current versions of Firefox.

Comment 20

[Will Roberts [:bws42]]

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.

Comment 23

[Sergio Basto]

this is a duplicated bug of #263049 , please fix it

Comment 24

[[e-mail]]

20.0 win7 beta still doesn't work

Comment 25

[Sergio Basto]

Attachment: bug449235.patch

I try this patch on firefox 22 and doesn't work , on xml finds

Comment 27

[baptiste33]

Still doesn't work on Firefox 30.0 on Win7

Comment 28

[Sergio Basto]

please mark this as duplicated of #263049 

there we have a patch that make some progresses

Comment 30

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates and 14 votes.
:enndeakin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 31

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.