Open Bug 839944 Opened 11 years ago Updated 2 years ago

in the Find bar, the Next and Previous buttons find different strings


(Core :: Find Backend, defect)

1.9.2 Branch
Windows 7




(Reporter: differcookie+bugzilla, Unassigned)



(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130201065344

Steps to reproduce:

Go to
Ctrl+F, type " Waffle House " with the spaces.
Press Next. Notice that there's only one found entry.
Press Previous. Notice that all of Waffle House's posts are now found.

Expected results:

I believe only one entry should be found.
Regression window(m-c)
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090623 Minefield/3.6a1pre ID:20090623050900
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090624 Minefield/3.6a1pre ID:20090624042426

4244c0215308	Neil Rashbrook — Bug 499115 nsFind fails to find again in certain form controls r+sr=bz
Blocks: 499115
Component: Untriaged → Find Backend
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
Version: 18 Branch → 1.9.2 Branch
No longer blocks: 499115
In local build,
Last Good: 5742b20d043a
First Bad: c6c685aa0379
Triggered by:
  c6c685aa0379	Robert O'Callahan — Bug 495385. Text frames adjacent to block boundaries that contain only collapsible whitespace cannot affect layout, so don't create them. r+sr=bzbarsky
Blocks: 495385
Component: Find Backend → Layout
Component: Layout → Find Backend
So far, this is my minimal test case:
> data:text/html,<table><tr><td> <input> Waffle House Millionaire
* The table is necessary
* The input is necessary
* The space in between is necessary!
(In reply to comment #3)
> > data:text/html,<table><tr><td> <input> Waffle House Millionaire
So, this is what happens:
1. We match the whitespace node against the space that begins the search string
2. We then continue to match the whitespace of the second text node
3. We match the rest of the search string
4. We then notice that the whitespace node has no frame and discard the whole match...
And of course the current code can find text if the middle is hidden...
Maybe if there's a frame for any part of the string, we should show the match, so only completely invisible strings are ignored?
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.