Does this occur with a "fresh" search, or is there a previously searched term already in the bar when you're opening it?

The "fresh" search scenario would have a middle step:

• Ctrl+f
• Type find => normally highlights the first match as you type
• Click ^ button => normally cycles to the last match in the page

In case it's relevant, could you also double-check that the "Match Case" option on the right end of the bar is not selected?

Sorry, I forgot to say that I can replicate it when opening an XML file in a tab.

When you download an XML file, it is opened in a new tab. It is not possible to use the up ^ button there to find a word.

Do you have a link to an XML file for quick reference and testing?

I don't have, but it is easy to replicate.

1. Open the notepad and paste the following:

<?xml version="1.0" encoding="UTF-8"?>
<presentation>
</presentation>

2. Save the file as .xml 3. Send this file to your gmail (for example) 4. Download and click Open 5. Choose to open in the browser (Firefox) 6. Open the FInd dialog and now type 'pre' to find the 'presentation' word 7. Click the up ^ button.

Here's a boring example that confirms what you are experiencing:

http://jeffersonscher.com/jeffersonscher_com_sitemap.xml

Since forward searching works, the lack of backwards searching seems like a bug.

Yeap, it seems to be a bug. And this is the only channel that I found to report this issue.

Not sure if this is going to be fixed.

It works fine on IE and Chrome.

Next step is to find an existing bug or submit a new one on https://bugzilla.mozilla.org/.

(Sorry I don't have time today.)

The DOM Inspector shows that there are actually two containers on the page: an html:div and an html:span The latter is hidden if there isn't a pref layout.xml.prettyprint set to false (this pref isn't there by default and needs to be created to test this).

• http://kb.mozillazine.org/layout.xml.prettyprint

The normal pretty print page has expand/collapse buttons and on that page searching back isn't working. With pretty print disabled or when viewing the page source you can search back and forward. I think that this is the same behavior as in other cases where the page is modified by JavaScript code on XUL code is being used and you can't easily go back in the DOM tree.