550124 - Find (Cmd-F, nsIWebBrowserFind) won't find anything in raw (pretty-printed) XML documents

Status: RESOLVED DUPLICATE of bug 263049

(Camino Graveyard :: General, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

STR:

1) View a “raw” XML document
2) Cmd-F and search for some text you see in the document

ER: Find finds the text
AR: Find returns "Not found"

In some documents, e.g. http://blog.mozilla.com/meeting-notes/feed (text/xml), you can click in the document and Find will work.

3) Click on the document
4) Repeat the search from 2

AR: Find finds the text

Even though the document is focused (e.g., space pages down), Find is somehow not finding the right document to search until you click on the document.

For other documents, though, clicking still can't coerce Find to start finding, e.g. http://dev.l-c-n.com/camino/text_services2.xhtml (application/xhtml+xml)

Note that in both cases FAYT will find things right off the bat.

XML that isn't pretty-printed, e.g. http://caminobrowser.org/blog/atom.xml (application/xml) and attachment 429294 [details] on bug 549052 (MathML served as text/xml), seems to allow Find to work OK.  It's not an isTextBasedContent issue, since the Find bar appears; it's something lower-level than that.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Not underlying MIME type, either; in this application/xhtml+xml document, Find finds just fine [∞ is Opt-5]:

http://hg.mozilla.org/mozilla-central/raw-file/18d0466b9a93/layout/reftests/mathml/mi-mathvariant-2-ref.xhtml (application/xhtml+xml, not pretty-printed)

Definitely looking like pretty-print is part of the problem.

Comment 2

[philippe (part-time)]

I put a couple of (identical) test files:
http://dev.l-c-n.com/camino/tests_b550124/
They only differ by mime type
test2.xhtml	- application/xhtml+xml
test3.xml	- application/xml
test4.xml2	- text/xml

The equivalent files with _b in the file name are styled and have no problem. 

.xhtml + pretty-print fails; .xml and .xml2 fail as described in comment 0.
One additional note on the .xml files. If you search for 'ipsum' in one pretty-print file, then go to the other pretty-print one and use Cmd-g, it fails unless you first click in the content. As stated in comment 0, content is focussed, paging (spacebar, arrow keys or page down key) work.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This might be the Core/embedding Find code's version of bug 263049.

(On 1.9.2, there was also bug 517866, whose fix only touched toolkit's typeaheadfind, not the Core/embedding Find code that we use. It's unclear how exactly that bug was different from bug 263049, other than that something regressed in some way due to FocusManager.  However, this bug seems like it was filed pre-1.9.2 (we mention FAYT!), so I'm guessing this is equivalent to bug 263049.)

Rather than dupe this to a bug that's stuck in Toolkit (which may or may not trigger a fix to the Core code we use), I'm going to set a dep for tracking purposes; if it ever looks like it's getting fixed, we can lobby for the fix to be made at the Gecko level rather than the toolkit/xulapp level.

Comment 4

[Sergio Basto]

reading 
https://bugzilla.mozilla.org/show_bug.cgi?id=449235#c10 and #11, make sense
please see this patch 
https://bug449235.bugzilla.mozilla.org/attachment.cgi?id=373726

Comment 5

[Sergio Basto]

(In reply to Sergio Basto from comment #4)
> reading 
> https://bugzilla.mozilla.org/show_bug.cgi?id=449235#c10 and #11, make sense
> please see this patch 
> https://bug449235.bugzilla.mozilla.org/attachment.cgi?id=373726

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

this bug is a duplicated of bug 263049

Comment 6

[Sergio Basto]

the fix for bug 263049 works on yours example . 
you may close this bug has fix in Target Milestone: mozilla34