Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050623 Firefox/1.0+ ID:2005062312 repro: 1.Open Firefox 2.Load a random page in the first tab (via bookmarks or type in locationbar) 3.Now type (! important) any random address , say http://www.mozilla.org/ in the locationbar. 4.press ctrl+f and type a word which you seen on that page in the findbar. result: nothing can be found I only have been able to reproduce using 1 tab in a window. With multiple tabs open it allways worked

in step 3 you need to press enter to load the page tested with old profile / -safe-mode / new profile+dir same result

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050623 Firefox/1.0+ WFM

FYI I filed bug 298639 which may be describing the same issue, though I see this problem with about:blank being the first page Firefox opens to. Peter, does this bug (bug 298622) occur for you if about:blank is the first page the browser opens to? If so, we should remove the "if first page was not about:blank" conditional from the summary. Also, did you mean to type "find fails on page with url typed" instead of "find fails one page with url typed"?

*** Bug 298639 has been marked as a duplicate of this bug. ***

(In reply to comment #3) > FYI I filed bug 298639 which may be describing the same issue, though I see this > problem with about:blank being the first page Firefox opens to. > > Peter, does this bug (298622) occur for you if about:blank is the first page > the browser opens to? - The browser opens with about:blank. - If I type about:blank for step 2 it does not appear > If so, we should remove the "if first page was not > about:blank" conditional from the summary. - Yep > Also, did you mean to type "find fails on page with url typed" instead of "find > fails one page with url typed"? - Yep

I tried this (anxious as always to find a cause and a cure for everything) with the addresses www.mozilla.org and www.mozillazine.org and at least here it seems to depend on the pref: user_pref("browser.sessionhistory.max_viewers", 5);

(In reply to comment #6) > I tried this (anxious as always to find a cause and a cure for everything) with > the addresses www.mozilla.org and www.mozillazine.org and at least here it seems > to depend on the pref: user_pref("browser.sessionhistory.max_viewers", 5); > Good catch confirming the bug appears with browser.sessionhistory.max_viewers !=0 the bug doesn't appear with browser.sessionhistory.max_viewers =0 ->Core ->history session cc bryner

Does anyone know if this regressed recently, or has it always been a problem with fastback turned on?

(In reply to comment #8) > Does anyone know if this regressed recently, or has it always been a problem > with fastback turned on? works in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050620 Firefox/1.0+ ID:2005062014 (release 1431pdt) fails in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050620 Firefox/1.0+ ID:2005062022 (release 2319pdt) checkins approximately : http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-06-20+13%3A30%3A00&maxdate=2005-06-20+23%3A00%3A00&cvsroot=%2Fcvsroot

This is a regression from bug 297173. Typeahead find relies on the pres shell destruction as a signal that it should no longer be used for find operations. With the cache on, of course, the pres shell stays around after you leave the page. I made it check that the shell is actually hooked up to a DOM window as well.

Comment on attachment 187456 [details] [diff] [review] patch >- *aResult = hasWrapped ? FIND_WRAPPED : FIND_FOUND; >+ if (hasWrapped) >+ *aResult = FIND_WRAPPED; >+ else >+ *aResult = FIND_FOUND; Well, I like it the way it was :-) r+sr=dbaron if you've tested that TAF is OK when you've fast-backed to a page as well (both if you have used it before leaving the first time and if you haven't)

(In reply to comment #11) > (From update of attachment 187456 [details] [diff] [review] [edit]) > >- *aResult = hasWrapped ? FIND_WRAPPED : FIND_FOUND; > >+ if (hasWrapped) > >+ *aResult = FIND_WRAPPED; > >+ else > >+ *aResult = FIND_FOUND; > > Well, I like it the way it was :-) Twas a warning fix. > > r+sr=dbaron if you've tested that TAF is OK when you've fast-backed to a page > as well (both if you have used it before leaving the first time and if you > haven't) >

Comment on attachment 187456 [details] [diff] [review] patch requesting approval

Comment on attachment 187456 [details] [diff] [review] patch a=chase

checked in

Comment on attachment 387563 [details] [diff] [review] mochitest test case This doesn't seem to be testing what this bug was about, which was find on the page that's loaded when you load your dummy page... It's probably best to test find on both pages in this test, just to cover all the bases.

Thanks for the review Boris, and for catching the fact that the test was testing Find on the wrong page. It now tests Find on both pages just for good measure.

Pushed test as http://hg.mozilla.org/mozilla-central/rev/00bd4f026a53