Closed Bug 379280 Opened 14 years ago Closed 13 years ago
Searching inside of a table not for all words possible
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4) Gecko/20070427 GranParadiso/3.0a4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4) Gecko/20070427 GranParadiso/3.0a4 I opened the page http://geizhals.at/?cat=cpup7&sort=r and clicked on the word "Klicken " so that the cursor is there. All words in the table except the word "Extreme" can be found. After I select a column in the table I can find the word "Extreme" I use gran paradiso alpha4rc2. Reproducible: Always Steps to Reproduce: 1. Open http://geizhals.at/?cat=cpup7&sort=r 2. Select the word "Klicken" to position the cursor on this word 3. Press Contrl+F 4. Enter the word "Extreme" Its not found until you select a word in the table. If you select the first row and enter the word again you will find this word.
I forgot to say that this test case works fine in 18.104.22.168
Component: Search → Find Toolbar / FastFind
QA Contact: search → fast.find
I can confirm this as a regression using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a5pre) Gecko/20070428 Minefield/3.0a5pre I'm not sure if this is a dupe, so not confirming yet. Can you look for a regression range using the builds at http://archive.mozilla.org/pub/firefox/nightly/ ?
Works fine in [2006-10-20-05] http://archive.mozilla.org/pub/firefox/nightly/2006-10-20-05-trunk/ but fails [2006-10-21-04] http://archive.mozilla.org/pub/firefox/nightly/2006-10-21-04-trunk/
Regression range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-10-20+05&maxdate=2006-10-21+04&cvsroot=%2Fcvsroot I'm not really sure what bug would cause this, but bug 357445 looks most suspicious... maybe?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
moving out bugs that don't need to block b1
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Yes, reminds me too of that bug, but this one looks even stranger. I'm seeing this assertion in a debug build: ###!!! ASSERTION: Text content wasn't nsIContent!: 'NS_SUCCEEDED(rv)', file c:/m ozilla-build/mozilla/embedding/components/find/src/nsFind.cpp, line 1317 So this indeed looks like a regression from bug 357445, somehow.
The start offset is after the index we check for at the top of the stack, so nsContentUtils::ComparePosition returns 1. The line asks if ComparePosition returns <= 0, so it says false. One line up, that leads to a NS_ERROR_FAILURE return, which leads to the assertion. The first failure stack is nearly identical, and the failure cause is identical.
This was a core content iterator regression. The patch in bug 414076 fixes this testcase. That said, if someone who's somewhat familiar with the findbar can use those APIs to write some regression mochitests for this bug and bug 414076, that would be very very nice...
Fixed by checkin for bug 414076.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Verified on 2 OS's: - Linux/Ubuntu 8.04 build: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008060309 Firefox/3.0 - Mac OS X 10.4.11 build: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9) Gecko/2008053008 Firefox/3.0
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.