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 http://suptg.thisisnotatrueending.com/archive/10964326/ 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) Good: http://hg.mozilla.org/mozilla-central/rev/c575412d976a Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090623 Minefield/3.6a1pre ID:20090623050900 Bad: http://hg.mozilla.org/mozilla-central/rev/5fe89f2c22f0 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090624 Minefield/3.6a1pre ID:20090624042426 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c575412d976a&tochange=5fe89f2c22f0 Suspected: 4244c0215308 Neil Rashbrook — Bug 499115 nsFind fails to find again in certain form controls r+sr=bz
Status: UNCONFIRMED → NEW
Component: Untriaged → Find Backend
Ever confirmed: true
Product: Firefox → Core
Version: 18 Branch → 1.9.2 Branch
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
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?
You need to log in before you can comment on or make changes to this bug.