User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 As per the SVG Spec, you must be able to search for text in an SVG (for accessibility, among other reasons). In MozSVG's implementation, there seems to be anomolous behavior here; if a text string is also present in an outer HTML host document, it will find the string and will account for (but not select) the instances in the SVG document as you click "Find Next"; if the string is not present in the HTML, it will simply not find the string at all in the SVG document. Reproducible: Always Steps to Reproduce: 1. Load sample file 2. Try to search for text 3. Fail Actual Results: Cannot search for text; no visual indicator of selection if there is indeed a sucessful result. Expected Results: Searching for text using the search bar should highlight matching strings in SVG documents (even if the strings are across <tspan> or <a> boundaries, while they are in the same <text> element... possibly even across <text> elements). Cycling through text selections should ideally step to each matching string in document order, though it may be preferrable to use presentation order (perhaps top-left to right-bottom, unless the specified text direction indicates otherwise). It may be adviseable to pan the current viewport to bring into view any matching string that is outside of the current viewport. This is very important for accessibility and for many WebApps.

I can reproduce this, but the symptoms vary slightly(?) from the original description. Apparently the "find" operation is partly implemented within SVG data. When searching for text contained within SVG data, what seems to work: * No status in the "Find" bar (where no match would show "not found"). * The number of matches on find-next seems about right (minus one? - using the wrap-around status message to count). What does NOT work: * There is NO visible indication of the matched text within the page. * The view is not scrolled so each match is visible (seems to scroll to the top of the SVG block). This is true both of a directly-loaded SVG page, and an SVG page loaded into HTML via the <object> tag. This is still marked as "Platform: x86 Windows XP" when in fact this seems a non-platform-specific problem. I can reproduce the problem on both Linux: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.13) Gecko/2009080315 Ubuntu/9.04 (jaunty) Firefox/3.0.13 and on Windows: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729) Hopefully someone has the rights to update the "Platform".

(In reply to comment #2) > Apparently the "find" operation is partly implemented within SVG > data. [...] > What does NOT work: > * There is NO visible indication of the matched text within the page. I'd say (by guessing) that this could be due to text find being looking at the DOM which (naturally) holds the text. I've already stated something similar, regarding lack of visual highlighting in a (tightly related) text selection issue [1] (from which this issue depends). By the way: could this bug be marked as confirmed? It's already been known for a while and the few votes seem to support it. ;-) [1] https://bugzilla.mozilla.org/show_bug.cgi?id=292498#c10

It seems that latest Opera and Safari browsers have descent highlighting support for text search inside SVG images. Both seem to require to open image itself. It would be nice if the search would also work in case the SVG object is embedded inside a HTML document, providing seamless integration with the regular HTML text search, but this might be part of a separate bug. :-)

+1 for fixing this ;-)

(In reply to Ferry Huberts from comment #6) > +1 for fixing this ;-) Using the vote feature (above, near "Importance") is a much more appropriate way for sharing this sort of feedback.

IE9 also implements this...

Bug 655877 will make searching on SVG text work.

Text find and highlight should now work in SVG documents, including SVG fragments within HTML documents, with bug 655877 and dependants landed.