Closed Bug 379280 Opened 15 years ago Closed 15 years ago

Searching inside of a table not for all words possible


(Toolkit :: Find Toolbar, defect, P4)






(Reporter: gerald_leder, Unassigned)



(Keywords: regression, testcase)


(2 files)

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 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 
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
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 ?
Keywords: regression
Whiteboard: [need-regression-range]
Regression range:

I'm not really sure what bug would cause this, but bug 357445 looks most suspicious... maybe?
Ever confirmed: true
Whiteboard: [need-regression-range]
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
Flags: blocking-firefox3?
Flags: blocking-firefox3? → blocking-firefox3+
Target Milestone: --- → Firefox 3 beta1
Target Milestone: Firefox 3 M7 → Firefox 3 M9
moving out bugs that don't need to block b1
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Priority: -- → P3
This reminds me of bug 336279.
Keywords: testcase
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.
Blocks: 357445
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.
Priority: P3 → P4
Depends on: 414076
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...
Flags: in-testsuite?
Fixed by checkin for bug 414076.
Closed: 15 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
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.