User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 For example, if you have word “finance” (ligature fi) in the page, than if you are looking for “finance” you won’t find anything. Reproducible: Always Steps to Reproduce: 1. Try to find word entering it without ligature, e.g. finance. Actual Results: If the word you are looking for is written with ligature in the page, you won’t find anything. Expected Results: You should be able to find the word.

Can you upload a testcase (or point to a page with the problem) and give more explicit steps to reproduce? See http://new.quality.mozilla.org/bug-writing-guidelines for information

This bug report can serve as a test case; try searching for the word "finance", and note that the first occurrence (which uses the fi ligature character) is not found. Web authors should not be using the Unicode "presentation forms" such as U+FB01 (fi); the content should simply use the character sequence "fi" here. The use of typographic ligatures like this belongs at the font-rendering level, not in the encoded data. IMO, this is not a Mozilla bug, it is an author error (essentially a form of spelling error). We could consider adding a "loose matching" search option, perhaps, in which case there are many such issues (using the Unicode "compatibility decompositions" as a basis would be a start), but it's questionable whether this would be generally useful, or mostly just confusing.

Thanks for the clarification. This appears to be a duplicate of bug 276757.

Bug 276757 was resolved specially for quotes, so unduping.

Bug 640856 is about accented letters, where composed and decomposed forms are defined to be canonically equivalent; as such, they should in principle -always- be treated as the same. This bug, however, is about cases that are -not- canonically equivalent, and so they fall into a "loose matching" category of some kind, similar to case folding, ignoring diacritics, matching "ß" with "ss", "№" with "No.", etc. Unicode's "compatibility decompositions" capture some of these possible equivalences, but not necessarily all cases; exactly what text sequences should be considered to match, and how to control this at the UI level, is rather nebulous and ill-defined. As such, I don't think we should dupe this to bug 640856. That bug would be fixed by a patch that deals specifically with canonical equivalence; this bug is part of a larger and messier issue, of which bug 276757 was just one isolated piece.

So I guess this bug would be the reason searching for !! doesn't find anything in http://dwarffortresswiki.org/index.php/40d:Fire This is parity-Chrome fwiw

Looks like duplicate of bug 202251...