Martijn Wargers (dead) Reporter
	Description • 18 years ago

Thanks to Alessandro Garberi for finding this bug.
With the steps to reproduce this is 100% reproducable to me.
Regression from bug 296639, this regressed between 2005-07-30 and 2005-07-31.

The steps to reproduce are very similar to bug 307375:
1. Toggle on about:config the pref. accessibility.typeaheadfind from false to true.
2. Make about:blank your start page.
3. Create a bookmark (toolbar) item with http://google.com as link.
4. Open Firefox.
5. Go to "Start">"All Programs" and open another window from firefox by
clicking on the program link, or just launch from a desktop icon or quick launch
bar.
6. Click on the bookmark with http://google.com as link. Focus will automatically be set on the Google search input box.
7. Try typing something on it. The Find Bar will popup and you will not be able
to write anything on it. After minimize and maximize this window you will be
able to write on Google search bar. 

I've taken the liberty of cc-ing a bunch of people (I hope you don't mind). This type of problem is reported a lot in bugzilla (see bug 320465) and the mozillazine forums.

I can't reproduce this in SeaMonkey, nor in my Firefox debug build for some reason. But I can reproduce this 100% with the regular (trunk) builds of Firefox.

	Dave Townsend [:mossop]
	Comment 1 • 18 years ago

I'm unable to reproduce this with current trunk, 2.0a3 or 1.5.0.3.

	Boris Zbarsky [:bzbarsky]
	Comment 2 • 18 years ago

Sounds like focus fun.  :(

	Mike Connor [:mconnor]
	Comment 3 • 18 years ago

Can people actually reproduce this in current branch?  If so, let's get a regression window ASAP.

	Mike Connor [:mconnor]
	Comment 4 • 18 years ago

clearing branch nomination, please try to reproduce this on current 1.8.1 builds and renominate then.

	Thomas Bertels
	Comment 5 • 18 years ago

Actually, bug 296639 regressed between 1.8.0.1 and 1.8.0.2, so https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&keywords=fixed1.8.0.2+verified1.8.0.2 can be used as a big regression window.
But it can't be reproduced on current 1.8.1 builds.

	Alex
	Comment 6 • 18 years ago

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

	Asa Dotzler [:asa]
	Comment 7 • 18 years ago

This is a common complaint and seems to happen to a lot of users (enough that there are 3rd party docs on the web listing workarounds.) QA confirms this is seen a lot and bug 320465 catches a lot of dupes. 

	Thomas Bertels
	Comment 8 • 18 years ago

(In reply to comment #7)
But it seems to be fixed on 1.8.1 builds.
Did somebody reproduced it on these builds ?

	Martijn Wargers (dead) Reporter
	Comment 9 • 18 years ago

(In reply to comment #8)
> (In reply to comment #7)
> But it seems to be fixed on 1.8.1 builds.
> Did somebody reproduced it on these builds ?

Yeah, indeed, I can't reproduce this on current branch builds. However, I can still reproduce this on current trunk builds. So I think the cause of this bug is still here on branch (but not manifestating, currently).

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 10 • 18 years ago

If it can't be reproduced on branch builds, it's not gonna block branch release even if the bad code is still in here. We're happy to call that serendipity for now :)

	Majken Connor [:Kensie]
	Comment 11 • 18 years ago

ooh some good action on this one,

I think this is the same issue as https://bugzilla.mozilla.org/show_bug.cgi?id=220900

This doesn't seem to happen when opening new windows using ctrl+n, only when opening a "new" process that gets added to the current one.

	erez
	Comment 12 • 18 years ago

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

	Tracy Walker [:tracy]
	Comment 13 • 18 years ago

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

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 14 • 18 years ago

We *think* this was fixed by bug 220900, but will block for confirmation. Oh Majken? Can I convince you to try out the STR with a recent trunk build and let us know if it's still happening and/or RESO INVALID this bug?

	Majken Connor [:Kensie]
	Comment 15 • 18 years ago

Beltzner - This particular instance, where it is reproducible with
typeaheadfind set to true, but not when it's set to false, is still happening.
Ty from Bug 320465 can reproduce it 100% of the time on mac with the refspoof
extension installed and 30-40% of the time (his estimation) without and
provided us with a regression window: "Builds before and including 2006-05-08
work perfectly fine in all cases.  From build 2006-05-09, the bug can be
triggered at will if the refspoof
extension is installed." 

He also has users that can reproduce it on XP and Ubuntu 30-40% of the time
(although I believe the extension doesn't make it easier to reproduce on
windows).  The only commonality we've established so far is that these are all
machines he set up and admins, although I'm waiting on an email response to
find out if there is some common hardware or software.

He also noted that this occurs regardless of how the second window is launched,
cmd+n was doing it as well.

	Martijn Wargers (dead) Reporter
	Comment 16 • 16 years ago

This is worksforme, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080901033305 Minefield/3.1b1pre