263049 - Find Previous doesn't work in XML document tree view

Status: VERIFIED FIXED

(Toolkit :: Find Toolbar, defect)

Description

[Kyr]

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.

Comment 1

[Uri Bernstein]

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.

Comment 2

[Aaron VanDevender]

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.

Comment 3

[Phil Ringnalda (:philor)]

*** Bug 308828 has been marked as a duplicate of this bug. ***

Comment 4

[Ria Klaassen (not reading all bugmail)]

*** Bug 339018 has been marked as a duplicate of this bug. ***

Comment 5

[Maxwell S Correia]

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

[Danny Sadinoff]

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

Comment 9

[Aaron Racine]

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.

Comment 12

[eric_schultz]

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).

Comment 14

[xinhua]

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

[Sjoerd]

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

[Terry]

Still doesn't work in firefox 3.0.11 and firefox 3.5.

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+2]]

It's not only the previous button but everything. Even the searched word cannot be found.

Comment 23

[jigsanster]

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

Comment 25

[Mike Hommey [:glandium]]

"Highlight all" exhibits the problem in an even more obvious way.

Comment 26

[Kevin S]

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

[Kevin S]

Attachment: Test XML file to repro the issue.

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.

Comment 29

[Alliz Gub]

Still present in Fx 3.6.13

Duplicate candidates : Bug 253261, Bug 445978, Bug 449235, Bug 452638, Bug 550124, Bug 599804.

Comment 32

[matteo sisti sette]

oh my god, SEVEN YEARS, this is crazy!

Comment 33

[Nicolas Barbulesco]

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

[PhoneixSegovia]

Also affect FF 7.0.1 on Ubuntu.

Comment 37

[Sebastian Freundt]

Also affects Nightly 11.0a1 (2011-12-11)

Comment 41

[Sergio Basto]

after 8 years nobody fix it, what a shame

Comment 42

[Alan Thomas]

(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.

Comment 43

[Steven Willis]

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

[Sergio Basto]

(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 ?

Comment 45

[Sebastian Freundt]

Still broken.

Version: 22.0a1 (2013-02-26)

Comment 46

[Bernhard Friedreich]

Still broken.

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

Comment 47

[Anson Ng]

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

[Nick Vikeras]

This bug is affecting me as well.

Comment 49

[Sergio Basto]

(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 ,

Comment 51

[Michael Shal [:mshal]]

Attachment: xml.patch

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?

Comment 52

[Mats Palmgren (inactive)]

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.

Comment 53

[Sergio Basto]

(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

[Sergio Basto]

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

also doesn't worked :(

Comment 55

[Alexander LAW]

(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

[Sergio Basto]

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

[Alexander LAW]

(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

[Sergio Basto]

(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

[Alexander LAW]

(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

[Sergio Basto]

(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

[Alexander LAW]

(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

[Camille]

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.

Comment 64

[Sergio Basto]

(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

[Alexander LAW]

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

[Sergio Basto]

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,

Comment 68

[Sergio Basto]

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

[Sergio Basto]

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.

Comment 72

[Alex Henrie]

Attachment: hack-2.patch

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

[Alex Henrie]

Attachment: salads.tar.xz

Also, if XMLPrettyPrint.xsl is loaded manually then there are no problems at all with the search feature.

Comment 74

[Sergio Basto]

(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

[Sergio Basto]

(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

[Alex Henrie]

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

Look at the first line of salads.xml.

Comment 77

[Sergio Basto]

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

[Sergio Basto]

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

Comment 80

[Boris Zbarsky [:bzbarsky]]

This bug is in the right component.

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

Comment 81

[Sergio Basto]

(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

[Alex Henrie]

Attachment: hack-3.patch

Here's another hack to get "Find previous" to work. Unfortunately, it doesn't work any better than hack-2.patch (see comment #72).

Comment 83

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: test.xml

Test XML file. RSS feeds get sniffed as RSS which is not what we want.

Comment 84

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 85

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 86

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

[Alexander LAW]

(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

Comment 88

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: 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!

Comment 89

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(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

[Alex Henrie]

Attachment: Find previous freeze backtrace

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.

Comment 91

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: better fix

Comment 92

[Alex Henrie]

(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 93

[Blake Kaplan (:mrbkap) (inactive)]

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?

Comment 94

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fa1ea174e770

1054617 is the followup bug to convert this code to use nsRange.

Comment 95

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/fa1ea174e770

Comment 96

[Alex Henrie]

I'm reducing the scope of this bug to the "Find Previous" issue; I've opened bug 1054845 to cover the "Highlight All" issue.

Comment 97

[Sergio Basto]

Thanks, I test the patch and it is working.
I built in http://copr.fedoraproject.org/coprs/sergiomb/firefox.bug263049/ :
firefox-31.0 with https://hg.mozilla.org/mozilla-central/raw-diff/fa1ea174e770/toolkit/components/typeaheadfind/nsTypeAheadFind.cpp 

you may try it with : 
yum --tmprepo=http://copr-be.cloud.fedoraproject.org/results/sergiomb/firefox.bug263049/fedora-20-x86_64/repodata/repomd.xml --nogpg  update firefox

Comment 99

[David Balažic]

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).

Comment 100

[Mats Palmgren (inactive)]

(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/

Comment 101

[Vasilica Tamas, QA [:vtamas]]

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.