Find toolbar pops up at google in second opened window




Find Toolbar
12 years ago
9 years ago


(Reporter: Martijn Wargers (dead), Unassigned)


({helpwanted, regression})

Windows XP
helpwanted, regression
Dependency tree / graph
Bug Flags:
blocking1.9 -
wanted1.9 +
blocking-firefox2 -

Firefox Tracking Flags

(Not tracked)




12 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 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
6. Click on the bookmark with 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.
I'm unable to reproduce this with current trunk, 2.0a3 or
Sounds like focus fun.  :(
Flags: blocking1.9a2?
Flags: blocking-firefox2?
Keywords: helpwanted, qawanted
Can people actually reproduce this in current branch?  If so, let's get a regression window ASAP.
clearing branch nomination, please try to reproduce this on current 1.8.1 builds and renominate then.
Flags: blocking-firefox2?

Comment 5

11 years ago
Actually, bug 296639 regressed between and, so can be used as a big regression window.
But it can't be reproduced on current 1.8.1 builds.

Comment 6

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


11 years ago
Flags: blocking-firefox2?

Comment 7

11 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. 

Comment 8

11 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 ?

Comment 9

11 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).

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 :)
Flags: blocking-firefox2? → blocking-firefox2-
ooh some good action on this one,

I think this is the same issue as

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.

Comment 12

11 years ago
*** Bug 345015 has been marked as a duplicate of this bug. ***
Flags: blocking1.9a2?
Flags: blocking1.9?
Flags: blocking-firefox3?
*** Bug 342140 has been marked as a duplicate of this bug. ***
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?
Flags: blocking-firefox3? → blocking-firefox3+
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.


11 years ago
Target Milestone: --- → Firefox 3 beta1


10 years ago
Target Milestone: Firefox 3 M7 → Firefox 3 M8


10 years ago
Target Milestone: Firefox 3 M8 → Firefox 3 M9


10 years ago
Target Milestone: Firefox 3 M9 → Firefox 3 M10


10 years ago
Target Milestone: Firefox 3 M10 → Firefox 3 M11


10 years ago
Priority: -- → P5


10 years ago
Flags: wanted-firefox3+
Flags: blocking-firefox3-
Flags: blocking-firefox3+
Target Milestone: Firefox 3 Mx → Firefox 3 M11


10 years ago
Keywords: qawanted


9 years ago
Product: Firefox → Toolkit

Comment 16

9 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
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.