285594 - search for xml tags

Status: RESOLVED WORKSFORME

(Toolkit :: Find Toolbar, defect)

Description

[federico razzoli]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; it-IT; rv:1.7.6) Gecko/20050226 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; it-IT; rv:1.7.6) Gecko/20050226 Firefox/1.0.1

When searching data in an XML document, it's possible that I'm searching a tag
or a parameter. Search should not cencern only tags content.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Ben Fowler]

Can you give fuller - more complete - steps to reproduce.

Comment 2

[federico razzoli]

I was asked to specify exactly how to reproduce this "bug".
1. open a Xml file
2. press crtl+f
3. search a tag contained in document.

Firefox won't find anything.
I understand that - in a HTML document - it's necessary to avoid finding the
tags (textarea, body, etc) cause it would be useless. But in an Xml document one
may need to find a specific tag.

Comment 3

[Ben Fowler]

Can you achieve what you want with 'View Source'?

Comment 4

[Elmar Ludwig]

While trying to reproduce this, I noticed some misbehaviour with find in XML
documents, but I'm not sure this is the same issue:

1. open XML document
2. press CTRL-F
3. enter string contained in document, press Enter
   -> match is found (ok)
4. press ESC to cancel find
5. click Reload
6. press CTRL-F
7. note that previous search string is still filled in, press Enter
   -> phrase not found (bug)

This does work correctly with HTML documents for me.

Tested on Firefox 1.0.1 (PPC, MacOS X 10.3, Gecko/20050225).

Comment 5

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 6

[Ben Fowler]

Whilst there is a nugget of goodness (I am all in favour of Firefox keeping
a full text index of cached or bookmarked documents, for example) in this 
RFE, I don't see that it is practical in its present form.

(Try on an SVG document).

The interested reader might want to look at
http://www.w3schools.com/xml/xml_display.asp and
http://www.w3schools.com/xml/cd_catalog_with_css.xml

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050822
Firefox/1.6a1
Saturday's Build.

The bug in comment 4 was NOT in - I saw the expected behaviour

Comment 7

[Martijn Wargers (dead)]

I think this is wfm, now. Although there is still bug 263049.

Comment 8

[Aaron Racine]

Reporter,

Following up on comment #7, do you still see this issue with the latest release of Firefox and a clean profile?  If so, can you provide a specific URL and tag that you're searching for when you're reproducing this?

Comment 9

[Martijn Wargers (dead)]

Attachment: testcase

Comment 10

[Martijn Wargers (dead)]

Actually this regressed now on trunk between 2007-02-28 and 2007-03-01:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-28+04&maxdate=2007-03-01+08&cvsroot=%2Fcvsroot
I think a regression from bug 372086, somehow.
Note that this didn't work without problems, though, see bug 263049.

Comment 11

[Aaron Racine]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/2007051502 Firefox/2.0.0.4

If I click in the test case page before searching, I can search all of it but then experience the behavior reported in bug 263049.

If I use this URL to test (from bug 346257):

http://fedoraproject.org/buildgroups/development/i386/buildroots.xml

then I can search for the content between tags (though sometimes it takes two tries for a successful find), as reported here.  However, once a word is highlighted from a find, I am then able to search the actual tags, as well, again with it behaving in line with bug 263049.

So, I can either find something in between the tags first or click in the page, and then I can search everything.  Martijn, can you reproduce this behavior?

Comment 12

[Martijn Wargers (dead)]

This is a recent regression on trunk.
Sorry, I probably should have filed a new bug on it, instead of confirming this bug.
Boris, I can still do that, if you prefer?

Comment 13

[Aaron Racine]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/2007060204 Minefield/3.0a6pre

The regression on trunk that I see is that you can't find anything at all in an XML Tree View.  Is this what you're referring to?

Comment 14

[Martijn Wargers (dead)]

Yes.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Yes, the trunk regression should be filed as a separate bug.

I'm not even clear on what this bug was about, to start with...

Comment 16

[Martijn Wargers (dead)]

Ok, I filed bug 384706 now for it.
I'm marking this bug WORKSFORME, it's working fine in Firefox2.
Sorry for the caused confusion.

Comment 17

[Aaron Racine]

It doesn't work fine in Fx2 for me, per comment #11.  In Fx2, can you go to the URL in comment #11 and successfully search for "packagereq", if you try to search only once?

Comment 18

[Martijn Wargers (dead)]

Yeah, I can see that problem. I guess you could file a new bug on that issue.
I don't think it's a good idea to reopen this bug for it, because this bug is already too confusing (thanks to me).