Closed
Bug 263049
Opened 20 years ago
Closed 10 years ago
Find Previous doesn't work in XML document tree view
Categories
(Toolkit :: Find Toolbar, defect)
Tracking
()
VERIFIED
FIXED
mozilla34
Tracking | Status | |
---|---|---|
firefox34 | --- | verified |
People
(Reporter: AKyritz, Assigned: roc)
References
()
Details
Attachments
(6 files, 3 obsolete files)
782 bytes,
patch
|
MatsPalmgren_bugz
:
feedback-
|
Details | Diff | Splinter Review |
495 bytes,
patch
|
Details | Diff | Splinter Review | |
1.70 KB,
patch
|
Details | Diff | Splinter Review | |
72 bytes,
application/xml
|
Details | |
14.97 KB,
text/plain
|
Details | |
3.66 KB,
patch
|
mrbkap
:
review+
|
Details | Diff | Splinter Review |
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•20 years ago
|
||
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•19 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.
Comment 3•19 years ago
|
||
*** Bug 308828 has been marked as a duplicate of this bug. ***
Comment 4•19 years ago
|
||
*** Bug 339018 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
QA Contact: fast.find
Comment 5•18 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•18 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
Updated•18 years ago
|
Assignee: bross2 → nobody
Updated•18 years ago
|
OS: Windows XP → All
Hardware: PC → All
Comment 9•17 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.
Updated•16 years ago
|
Product: Firefox → Toolkit
Comment 12•16 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).
Comment 14•16 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•16 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•15 years ago
|
||
Still doesn't work in firefox 3.0.11 and firefox 3.5.
Comment 21•15 years ago
|
||
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
Comment 23•15 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
Comment 25•15 years ago
|
||
"Highlight all" exhibits the problem in an even more obvious way.
Comment 26•14 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•14 years ago
|
||
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.
Blocks: 550124
Comment 29•14 years ago
|
||
Still present in Fx 3.6.13 Duplicate candidates : Bug 253261, Bug 445978, Bug 449235, Bug 452638, Bug 550124, Bug 599804.
Comment 32•13 years ago
|
||
oh my god, SEVEN YEARS, this is crazy!
Comment 33•13 years ago
|
||
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•13 years ago
|
||
Also affect FF 7.0.1 on Ubuntu.
Comment 37•13 years ago
|
||
Also affects Nightly 11.0a1 (2011-12-11)
Comment 41•13 years ago
|
||
after 8 years nobody fix it, what a shame
Comment 42•13 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•12 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•12 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 ?
Comment 45•12 years ago
|
||
Still broken. Version: 22.0a1 (2013-02-26)
Comment 46•11 years ago
|
||
Still broken. Version: 25.0a1 (2013-07-30) running on Ubuntu 12.10
Comment 47•11 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•11 years ago
|
||
This bug is affecting me as well.
Comment 49•11 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•11 years ago
|
Comment 51•11 years ago
|
||
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?
Updated•11 years ago
|
Attachment #8336573 -
Flags: feedback?(matspal)
Comment 52•11 years ago
|
||
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•11 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•11 years ago
|
||
(In reply to Michael Shal [:mshal] from comment #51) > Created attachment 8336573 [details] [diff] [review] > xml.patch also doesn't worked :(
Comment 55•11 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•11 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•11 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•11 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•11 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•11 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•11 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•11 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.
Updated•11 years ago
|
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•10 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•10 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•10 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,
Comment 68•10 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•10 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.
Assignee | ||
Updated•10 years ago
|
Attachment #453811 -
Attachment mime type: application/xml → text/xml
Comment 72•10 years ago
|
||
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•10 years ago
|
||
Also, if XMLPrettyPrint.xsl is loaded manually then there are no problems at all with the search feature.
Comment 74•10 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•10 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•10 years ago
|
||
(In reply to Sergio Basto from comment #75) > How you do that ? Look at the first line of salads.xml.
Comment 77•10 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•10 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
![]() |
||
Comment 80•10 years ago
|
||
This bug is in the right component. See bug 1044507 comment 1 for why comment 77 is not a workable solution.
Comment 81•10 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•10 years ago
|
||
Here's another hack to get "Find previous" to work. Unfortunately, it doesn't work any better than hack-2.patch (see comment #72).
Assignee | ||
Comment 83•10 years ago
|
||
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
Assignee | ||
Comment 84•10 years ago
|
||
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.
Assignee | ||
Comment 85•10 years ago
|
||
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.
Assignee | ||
Comment 86•10 years ago
|
||
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•10 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
Assignee | ||
Comment 88•10 years ago
|
||
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)
Assignee | ||
Comment 89•10 years ago
|
||
(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•10 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•10 years ago
|
Attachment #8472495 -
Attachment description: ind previous freeze backtrace → Find previous freeze backtrace
Assignee | ||
Comment 91•10 years ago
|
||
Attachment #8472269 -
Attachment is obsolete: true
Attachment #8472269 -
Flags: review?(mrbkap)
Attachment #8472941 -
Flags: review?(mrbkap)
Comment 92•10 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 93•10 years ago
|
||
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+
Assignee | ||
Comment 94•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/fa1ea174e770 1054617 is the followup bug to convert this code to use nsRange.
Comment 95•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/fa1ea174e770
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Comment 96•10 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
Updated•10 years ago
|
Flags: qe-verify+
Comment 97•10 years ago
|
||
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•10 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).
Comment 100•10 years ago
|
||
(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•10 years ago
|
||
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
status-firefox34:
--- → verified
You need to log in
before you can comment on or make changes to this bug.
Description
•