379280 - Searching inside of a table not for all words possible

Status: VERIFIED FIXED

(Toolkit :: Find Toolbar, defect, P4)

Description

[Gerald]

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.

Comment 1

[Gerald]

I forgot to say that this test case works fine in 2.0.0.3

Comment 2

[Samuel Sidler (old account; do not CC)]

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

Comment 3

[Gerald]

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/

Comment 4

[Samuel Sidler (old account; do not CC)]

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?

Comment 5

[Mike Connor [:mconnor]]

moving out bugs that don't need to block b1

Comment 6

[Jesse Ruderman]

Attachment: testcase (search for 'extreme')

Comment 7

[Jesse Ruderman]

This reminds me of bug 336279.

Comment 8

[Martijn Wargers (dead)]

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.

Comment 9

[Alex Vincent [:WeirdAl]]

Attachment: stack trace where (second) failure begins

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.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[Boris Zbarsky [:bzbarsky]]

Fixed by checkin for bug 414076.

Comment 12

[Paul Craciunoiu [:paulc]]

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