Find Previous doesn't work in XML document tree view

VERIFIED FIXED in Firefox 34

Status

()

defect
VERIFIED FIXED
15 years ago
5 years ago

People

(Reporter: AKyritz, Assigned: roc)

Tracking

1.0 Branch
mozilla34
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox34 verified)

Details

()

Attachments

(6 attachments, 3 obsolete attachments)

Reporter

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

Using Find Previous button in the FindToolbar (STRG+F) in xml document tree view
doesn't work.
Find Next ist correct.

Sample XML ist:
<?xml version="1.0" encoding="windows-1252" standalone="yes"?>
<a>
<b/>
<b/>
</a>

Reproducible: Always
Steps to Reproduce:
1. Open Sample XML-File
2. STRG+F search for b Enter -> finds first b, Find Next finds next b
3. Find Previous alway says 'Phrase not found'.




This doesn't work in Mozilla (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.3) Gecko/20040910) too. Maybe this is related to gecko.
I'm seeing this on Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.3)
Gecko/20041005 Firefox/0.10.1.
Also, when searching forward, the search does not wrap to the top of the
document when reaching the bottom.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

14 years ago
I'm seeing this on Linux too [Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10)
Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6]

I can use the find function to search for things and they will be highlighted,
but text entry box is always red, the find next and find previous buttons don't
work, and it always says it wrapped the search with out finding anything.
*** Bug 308828 has been marked as a duplicate of this bug. ***
*** Bug 339018 has been marked as a duplicate of this bug. ***
QA Contact: fast.find

Comment 5

13 years ago
This doesn't work in Firefox 2.0 too: Mozilla/5.0 (Windows; U; Win 9x 4.90; pt-BR; rv:1.8.1) Gecko/20060918 Firefox/2.0

Comment 6

13 years ago
I'm seeing this in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Assignee: bross2 → nobody
Duplicate of this bug: 373617
OS: Windows XP → All
Hardware: PC → All
Duplicate of this bug: 381085

Comment 9

12 years ago
Now that bug 384706 has been fixed, I can reproduce this in trunk: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/2007062304 Minefield/3.0a6pre.

Duplicate of this bug: 425628

Updated

11 years ago
Duplicate of this bug: 435847
Product: Firefox → Toolkit

Comment 12

11 years ago
Ran into this today using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 (.NET CLR 3.5.30729).
Duplicate of this bug: 466177

Comment 14

11 years ago
This bug is about 'find previous' is broken for xml document, but I want to add a fact that, even 'find next' has problems in xml document too, it does not wrap to the beginning of xml document when it reaches the end, which is the (correct) behavior of 'find next' in other documents.

Comment 15

10 years ago
In nsFind::NextNode, mIterator->Prev() and mIterator->getCurrentNode() are called to get the previous node to search in. In an XML file, mIterator->getCurrentNode() simply returns null.

Comment 16

10 years ago
Still doesn't work in firefox 3.0.11 and firefox 3.5.

Updated

10 years ago
Duplicate of this bug: 456960

Updated

10 years ago
Duplicate of this bug: 519941

Updated

10 years ago
Duplicate of this bug: 533400
It's not only the previous button but everything. Even the searched word cannot be found.
Summary: Find Previous doesn't work in xml document tree view → Find doesn't work in xml document tree view
Duplicate of this bug: 538966

Comment 23

9 years ago
i have same problem
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2) Gecko/20100115 Firefox/3.6

Updated

9 years ago
Duplicate of this bug: 537319
"Highlight all" exhibits the problem in an even more obvious way.

Comment 26

9 years ago
Reproduced with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4 ( .NET CLR 3.5.30729)

It's not just the previous button that is broken, 'highlight all' is completely dysfunctional and 'find next' will not wrap to the beginning of the document after reaching the last positive search result.

Comment 27

9 years ago
Posted file Test XML file to repro the issue. (obsolete) —
This xml file should allow you to repro this issue 100%.
Repro Steps:
1. Open testfile.xml in firefox in a recent build
2. Press 'ctrl + f' to open search feature
3. type 'food' in the search box
4a. Select 'highlight all' or 'previous'
4b. Select 'Next' 3 times.

Result:
Highlight all and previous is never able to find, identify, or highlight the search term. Next will find each item if the focus is above each term, but will not wrap to the top of the page.

Expected:
It is expected that highlight all will find each instance of the term and highlight it. 'Previous' button will find the previous item on the page or wrapping to last instance in the document if focus is at the top. Next should wrap to the beginning of the doc if it reaches the end.
Duplicate of this bug: 585945

Comment 29

9 years ago
Still present in Fx 3.6.13

Duplicate candidates : Bug 253261, Bug 445978, Bug 449235, Bug 452638, Bug 550124, Bug 599804.
Duplicate of this bug: 664063
Duplicate of this bug: 683835
oh my god, SEVEN YEARS, this is crazy!
Fresh FF 7.0.1 on Windows.

I load an XML document. It displays. I press crtl F. I type an existing word. I incorrectly get "not found". I click in the document. I retry. Now the result is found. I press F3... I get the next results... I have a bunch of results. But, after the first result, I get every result with an incorrect indicator "end of document reached, search looped from the top". After the last result, the search must loop, as it does usually. It doesn't. Instead, it says "not found". I even press crtl Beginning. I F3 again. I again get incorrectly "not found". With my mouse, I select some letters at the beginning of the document. I F3. Now, I get the first result, this is correct ; but with an incorrect indicator "end of document reached, search looped from the top".

Comment 34

8 years ago
Also affect FF 7.0.1 on Ubuntu.

Updated

8 years ago
Duplicate of this bug: 641596

Updated

8 years ago
Duplicate of this bug: 707102
Also affects Nightly 11.0a1 (2011-12-11)

Updated

8 years ago
Duplicate of this bug: 712591
Duplicate of this bug: 719635

Updated

8 years ago
Duplicate of this bug: 452638

Comment 41

8 years ago
after 8 years nobody fix it, what a shame

Comment 42

7 years ago
(In reply to Henrik Skupin (:whimboo) from comment #21)
> It's not only the previous button but everything. Even the searched word
> cannot be found.

That looks like bug 449235.
Summary: Find doesn't work in xml document tree view → Find Previous doesn't work in xml document tree view

Comment 43

7 years ago
So it looks like there are 3 related bugs that are still open, this one, bug 550124, and bug 449235. They all seem to be describing the same three issues with find and xml documents:

1) Initial FAYT doesn't find anything even though the text is definitely there (this happens intermittently). The user has to click in the document first.
2) The previous button never works even after getting FAYT to work.
3) After reaching the last match, FAYT never loops to be beginning.

Should this and/or the other bugs be closed as duplicates and just one of these bugs be elevated in importance so it gets worked on? This bug has been open for almost 8 years, 449235 has been open almost 4 years, and 550124 over 2 years. Is anyone even looking at this issue?

BTW Firefox 13.0.1 on Ubuntu.

Comment 44

7 years ago
(In reply to Steven Willis from comment #43)
> Should this and/or the other bugs be closed as duplicates and just one of
> these bugs be elevated in importance so it gets worked on? 

don't close before fix , and yes should put it in biggest importance 

> This bug has been
> open for almost 8 years, 449235 has been open almost 4 years, and 550124
> over 2 years. Is anyone even looking at this issue?

this really sucks , 8 years to fix a structure (basic) bug ?
Still broken.

Version: 22.0a1 (2013-02-26)
Still broken.

Version: 25.0a1 (2013-07-30) running on Ubuntu 12.10

Comment 47

6 years ago
I'm surprised this simple bug is still broken in the 24.0 since this was reported in 2004.

Basically Find Previous works, but only restricted in the scope of the tag (or tree node) the cursor is at.

<test>
<value>hello world</value>
<value>hello firefox</value>
</test>

If you click on (or highligh) "firefox" in the XML tree view, Find Previous for the term "hello" will find the "hello" in the tag <value>hello firefox</value>, but it does not go beyond the current tag, which means it CANNOT find the first "hello" in the tag <value>hello world</value>.

Comment 48

6 years ago
This bug is affecting me as well.

Comment 49

6 years ago
(In reply to Alan Thomas from comment #42) 
> That looks like bug 449235.

yes bug 449235 , should also be marked as duplicated of this one (only have 4 years)  . 

The strange thing in this bugzilla is this bug is not assign to anyone ,

Updated

6 years ago
Duplicate of this bug: 923419
Posted patch xml.patchSplinter Review
I'm not sure if it helps toward a real solution, but this patch seems to fix the issue. For some reason, the IndexOf method is returning -1, which seems to cause the search to zero in on the wrong value. By flipping -1 to 1, I can search forward & backward in a pretty-printed XML file. It still doesn't wrap when the last match is found like it does in an HTML file, though.

Also, this might be a red-herring, but this error check is triggered in the XML case: http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsRange.cpp#2111

Maybe that will help someone more knowledgeable get a real fix in?
Attachment #8336573 - Flags: feedback?(matspal)
Comment on attachment 8336573 [details] [diff] [review]
xml.patch

Does the patch in bug 655947 fix this bug?  If so, I think I prefer
that patch.
Attachment #8336573 - Flags: feedback?(matspal) → feedback-

Comment 53

6 years ago
(In reply to Mats Palmgren (:mats) from comment #52)

> 
> Does the patch in bug 655947 fix this bug?  If so, I think I prefer
> that patch.

no , the patch of bug 655947 doesn't fix this bug I just test it , now I'm going to test the patch on this bug, I will give you feed back in a few hours or tomorrow .

Thanks to try fix this bug

Comment 54

6 years ago
(In reply to Michael Shal [:mshal] from comment #51)
> Created attachment 8336573 [details] [diff] [review]
> xml.patch

also doesn't worked :(
No longer depends on: 655947

Comment 55

6 years ago
(In reply to Sergio Basto from comment #53)
> (In reply to Mats Palmgren (:mats) from comment #52)
> 
> > 
> > Does the patch in bug 655947 fix this bug?  If so, I think I prefer
> > that patch.
> 
> no , the patch of bug 655947 doesn't fix this bug I just test it , now I'm
> going to test the patch on this bug, I will give you feed back in a few
> hours or tomorrow .
> 
> Thanks to try fix this bug

Please, explain how did you test the patch https://bug655947.bugzilla.mozilla.org/attachment.cgi?id=738059 ?
I just tested it once again and it still works.

WBR,
Alexander

Comment 56

6 years ago
I do a fedora 19 package.
fedpkg clone firefox
cd firefox/
wget https://bug655947.bugzilla.mozilla.org/attachment.cgi?id=738059 -O bug655947.patch
fedpkg switch-branch f19
vi firefox.spec [1]
fedpkg srpm
mock -r fedora-19-x86_64 --rebuild ./firefox-26.0-5.fc19.src.rpm --no-clean
as root:
yum --tmprepo=/var/lib/mock/fedora-19-x86_64/result/repodata/repomd.xml update firefox --nogpg -y

find in xml, stuck in last searched item,  
I'm going reboot computer , and use  a clean profile just to be sure . 
 
[1]
git diff 
+Release:        5%{?pre_tag}%{?dist}
+Patch17:        bug655947.patch
+%patch17 -p1 -b .bug655947

I check build.logs and the patch is applied to firefox source.

Comment 57

6 years ago
(In reply to Sergio Basto from comment #56)
> find in xml, stuck in last searched item,  
> I'm going reboot computer , and use  a clean profile just to be sure . 

If I understand you right, you tested whether search wraps araound from the end to the start, but the proposed patch is for fixing 'Find Previous' function. So I just search for one of multiple string instances and then try to search backward.

Comment 58

6 years ago
(In reply to Alexander LAW from comment #57) 
> If I understand you right, you tested whether search wraps araound from the
> end to the start, but the proposed patch is for fixing 'Find Previous'
> function. So I just search for one of multiple string instances and then try
> to search backward.

I tested both , don't search backward and don't wraps around.

Comment 59

6 years ago
(In reply to Sergio Basto from comment #58)
> (In reply to Alexander LAW from comment #57) 
> > If I understand you right, you tested whether search wraps araound from the
> > end to the start, but the proposed patch is for fixing 'Find Previous'
> > function. So I just search for one of multiple string instances and then try
> > to search backward.
> 
> I tested both , don't search backward and don't wraps around.

It's very strange indeed. I build and run the Firefox binary using https://developer.mozilla.org/en-US/docs/Simple_Firefox_build instructions.

Comment 60

6 years ago
(In reply to Alexander LAW from comment #59)
> It's very strange indeed. I build and run the Firefox binary using
> https://developer.mozilla.org/en-US/docs/Simple_Firefox_build instructions.

Are you building Firefox 29 Alfa ?

Comment 61

6 years ago
(In reply to Sergio Basto from comment #60)
> Are you building Firefox 29 Alfa ?

Yes, I am building current development version. And the patch worked in April with that version too.

Comment 62

6 years ago
Still Broken
Version 26.0 (22/01/2014) Windows 7 64-bit
Will trial the patch as well as a workaround but it seems strange there is no official fix yet.
Duplicate of this bug: 962107
Summary: Find Previous doesn't work in xml document tree view → 'Find Previous' and 'Highlight All' buttons don't work in xml document tree view

Comment 64

5 years ago
(In reply to Alexander LAW from comment #61)
> (In reply to Sergio Basto from comment #60)
> > Are you building Firefox 29 Alfa ?
> 
> Yes, I am building current development version. And the patch worked in
> April with that version too.

patch doesn't work applied on firefox-29.0-5.fc20.x86_64 

built like I described in comment #56

Comment 65

5 years ago
I just build firefox for fc20 just as you described.
"Find previous" works for me.

Please check the following:
.x86_64.rpm: https://drive.google.com/file/d/0B9MDX32ABaUbQW5Yeko2RUY2UHM/edit?usp=sharing
.src.rpm: https://drive.google.com/file/d/0B9MDX32ABaUbX0FoRnY2Y0ZTcDQ/edit?usp=sharing

Comment 66

5 years ago
today on my build, it is working !!! I should fail same restart, the match case also works , "Highlight All" no , and when reached end of page doesn't continue from top .

But, anyway, we should applied this patch upstream, since makes find previous on xml documents works . 

Thanks,

Updated

5 years ago
Duplicate of this bug: 1006618

Comment 68

5 years ago
Hi , 
what is the status of this patch [1] , when it is included in firefox code ? 

[1]
https://bugzilla.mozilla.org/attachment.cgi?id=8336573

Comment 69

5 years ago
Hi, I use new copr Fedora builder to build released Firefox with this patch, if anyone want to try it may do: 
 
yum --tmprepo=http://copr-be.cloud.fedoraproject.org/results/sergiomb/firefox.bug263049/fedora-20-x86_64/repodata/repomd.xml --nogpg  update firefox 

I had built for Fedora 20 . i386 e x86_64 , if anyone want it for other environment please email me.

Updated

5 years ago
Duplicate of this bug: 1029111

Updated

5 years ago
Duplicate of this bug: 1032566
Attachment #453811 - Attachment mime type: application/xml → text/xml

Comment 72

5 years ago
Posted patch hack-2.patchSplinter Review
For what it's worth, "Find previous" works if you comment the following out of nsContentIterator::Next:

   if (mCurNode == mFirst) {
     mIsDone = true;
     return;
   }

However, "Highlight all" still doesn't work, Firefox still says that it has wrapped around the document when it hasn't, and it still won't wrap around the document when it's supposed to.

Comment 73

5 years ago
Posted file salads.tar.xz (obsolete) —
Also, if XMLPrettyPrint.xsl is loaded manually then there are no problems at all with the search feature.

Comment 74

5 years ago
(In reply to Alex Henrie from comment #73)
> Created attachment 8459967 [details]
> salads.tar.xz
> 
> Also, if XMLPrettyPrint.xsl is loaded manually 

how you that ? 

> then there are no problems at
> all with the search feature.

Have a fix would be great , what yours salads.tar.xz helps ? 
diff mozilla-release/content/xml/document/resources/XMLPrettyPrint.xsl salads/ -ups
Files mozilla-release/content/xml/document/resources/XMLPrettyPrint.xsl and salads/XMLPrettyPrint.xsl are identical
and salads.xml seems a non sense to me .
could you attach all patch at once and obsolete the others ? please 
Thanks

Comment 75

5 years ago
(In reply to Alex Henrie from comment #73) 
> Also, if XMLPrettyPrint.xsl is loaded manually then there are no problems at
> all with the search feature.

How you do that ? 

sorry for typo

Comment 76

5 years ago
(In reply to Sergio Basto from comment #75)
> How you do that ? 

Look at the first line of salads.xml.

Comment 77

5 years ago
yeah ! adding this line (1) in begin of xml files with XMLPrettyPrint.xsl in same directory, 
fix all problems without any patch , tested with new firefox-31 

Thanks for your reply 

(1)
<?xml-stylesheet type="text/xsl" href="XMLPrettyPrint.xsl" ?>

Comment 78

5 years ago
from bugs #64945, #185873, #182031 I saw this bug is not well classified , should be Product: Core and Component : XML .
Could anyone with privileges change Product and component of this bug ? , please
Duplicate of this bug: 1044507
This bug is in the right component.

See bug 1044507 comment 1 for why comment 77 is not a workable solution.

Comment 81

5 years ago
(In reply to Boris Zbarsky [:bz] from comment #80)
> This bug is in the right component.
> 
> See bug 1044507 comment 1 for why comment 77 is not a workable solution.

because I don't know add one line to an xml locate in internet ,

mozilla-release/content/xml/document/src/nsXMLPrettyPrinter.cpp should load it correctly but don't

Comment 82

5 years ago
Posted patch hack-3.patchSplinter Review
Here's another hack to get "Find previous" to work. Unfortunately, it doesn't work any better than hack-2.patch (see comment #72).
Posted file test.xml
Test XML file. RSS feeds get sniffed as RSS which is not what we want.
Attachment #453811 - Attachment is obsolete: true
Attachment #8459967 - Attachment is obsolete: true
In that test file, if you search for "hello" until you've found the match in the second <value> element, and then search again, we don't wrap and instead say there's no match.

The problem is that mStartPointRange->CompareBoundaryPoints(nsIDOMRange::START_TO_START, mSearchRange, &rangeCompareResult) in nsTypeAheadFind::FindItNow returns -1, but it shouldn't. mStartPointRange is in the text node child of the second <value> element. mSearchRange's start position is offset 0 in the XML document's root element. So CompareBoundaryPoints should return 1 here. Return -1 means hasWrapped is initially set to true, which means when we don't find a match after the second <value> element, we don't try again from the beginning of the document.
And that's because XMLPrettyPrint.xml defines an XBL binding that wraps the entire file content in an anonymous DIV. nsContentUtils::ComparePoints gets to the end and tries to check "parent->IndexOf(child1) < aOffset2" where 'parent' is this anonymous DIV and aOffset2 is 0. But that IndexOf call returns -1 because child1 is anonymous, i.e. not in the real child list. So we decide that it's before the start its parent element. Ooops.

nsRange::CompareBoundaryPoints and nsContentUtils::ComparePoints simply aren't up to the job of handling anonymous content; at least, anonymous container elements.
I have a simple patch to work around that issue.

Now the bigger problem is that nsFind walks the DOM starting from the non-anonymous XML document. Unfortunately all the content of that document is hidden away in a display:none <span> created by the XBL binding doc. The visible content has all been created by XMLPrettyPrint.xsl and is anonymous content, not reachable by the content iterator used when nsFind starts in non-anonymous content.

Comment 87

5 years ago
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #85)
> And that's because XMLPrettyPrint.xml defines an XBL binding that wraps the
> entire file content in an anonymous DIV. nsContentUtils::ComparePoints gets
> to the end and tries to check "parent->IndexOf(child1) < aOffset2" where
> 'parent' is this anonymous DIV and aOffset2 is 0. But that IndexOf call
> returns -1 because child1 is anonymous, i.e. not in the real child list. So
> we decide that it's before the start its parent element. Ooops.

Please look at https://bugzilla.mozilla.org/show_bug.cgi?id=655947
Posted patch fix (obsolete) — Splinter Review
I have no idea who should review this, sorry...

Alex, I hate to be "that guy", but I don't really have time to write an automated test for this so if you want to make sure this keeps working, maybe you could :-) Thanks!
Assignee: nobody → roc
Attachment #8472269 - Flags: review?(mrbkap)
(In reply to Alexander LAW from comment #87)
> (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #85)
> > And that's because XMLPrettyPrint.xml defines an XBL binding that wraps the
> > entire file content in an anonymous DIV. nsContentUtils::ComparePoints gets
> > to the end and tries to check "parent->IndexOf(child1) < aOffset2" where
> > 'parent' is this anonymous DIV and aOffset2 is 0. But that IndexOf call
> > returns -1 because child1 is anonymous, i.e. not in the real child list. So
> > we decide that it's before the start its parent element. Ooops.
> 
> Please look at https://bugzilla.mozilla.org/show_bug.cgi?id=655947

Thanks. I should have looked at that earlier. However, the actual fix for this bug does not depend on that.

Comment 90

5 years ago
Robert: Wow, thanks! (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #88)
> Created attachment 8472269 [details] [diff] [review]
> fix
> 
> I have no idea who should review this, sorry...
> 
> Alex, I hate to be "that guy", but I don't really have time to write an
> automated test for this so if you want to make sure this keeps working,
> maybe you could :-) Thanks!

Wow, thank you! If I can find where HTML search is tested, it should be pretty easy to add an XML test.

There is one new problem though: With your patch applied, if I try to search backwards until I hit the beginning of the document and wrap around, Firefox freezes.

Updated

5 years ago
Attachment #8472495 - Attachment description: ind previous freeze backtrace → Find previous freeze backtrace
Posted patch better fixSplinter Review
Attachment #8472269 - Attachment is obsolete: true
Attachment #8472269 - Flags: review?(mrbkap)
Attachment #8472941 - Flags: review?(mrbkap)

Comment 92

5 years ago
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #91)
> Created attachment 8472941 [details] [diff] [review]
> better fix

Great, no more crash! "Highlight All" still doesn't work, but we can leave that for later.
Comment on attachment 8472941 [details] [diff] [review]
better fix

Review of attachment 8472941 [details] [diff] [review]:
-----------------------------------------------------------------

File a followup to convert this code over to using nsRange, I'd be happy to mentor such a bug?
Attachment #8472941 - Flags: review?(mrbkap) → review+
https://hg.mozilla.org/mozilla-central/rev/fa1ea174e770
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34

Comment 96

5 years ago
I'm reducing the scope of this bug to the "Find Previous" issue; I've opened bug 1054845 to cover the "Highlight All" issue.
Summary: 'Find Previous' and 'Highlight All' buttons don't work in xml document tree view → Find Previous doesn't work in XML document tree view
Version: unspecified → 1.0 Branch
Flags: qe-verify+
Depends on: 1055456

Comment 99

5 years ago
I am using FF 33 on Win7 and this still does not work.

I open the example URL, search for 'b' and forward search works, but backward not.

Maybe a better example: search for 'e'. Forward works, but backward not (except in some cases, in the same line of text between XML tags).
(In reply to David Balažic from comment #99)
> I am using FF 33 on Win7 and this still does not work.

The fix is in FF 34, which will be released in ~5 weeks.
You can download FF 34 beta if you want it earlier (and help
us test it):  https://www.mozilla.org/en-US/firefox/channel/
Based on Comment 96 I verified only "Find Previous" issue that I managed to reproduce on Nightly 34.0a1 (2014-08-01) using Windows 7 x64.

Verified fixed on Firefox 34 Beta 9 build 2 (20141114133026) using Windows 7 x64, Ubuntu 12.04 x32 and Mac OSX 10.7.5.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.