Closed Bug 339465 Opened 19 years ago Closed 16 years ago

Find toolbar pops up at google in second opened window

Categories

(Toolkit :: Find Toolbar, defect, P5)

x86
Windows XP
defect

Tracking

()

RESOLVED WORKSFORME
mozilla1.9beta3

People

(Reporter: martijn.martijn, Unassigned)

References

Details

(Keywords: helpwanted, regression)

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.
I'm unable to reproduce this with current trunk, 2.0a3 or 1.5.0.3.
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?
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.
*** Bug 345078 has been marked as a duplicate of this bug. ***
Flags: blocking-firefox2?
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.
(In reply to comment #7) But it seems to be fixed on 1.8.1 builds. Did somebody reproduced it on these builds ?
(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 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.
*** 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.
Target Milestone: --- → Firefox 3 beta1
Target Milestone: Firefox 3 M7 → Firefox 3 M8
Target Milestone: Firefox 3 M8 → Firefox 3 M9
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Priority: -- → P5
Flags: wanted-firefox3+
Flags: blocking-firefox3-
Flags: blocking-firefox3+
Target Milestone: Firefox 3 Mx → Firefox 3 M11
Keywords: qawanted
Product: Firefox → Toolkit
This is worksforme, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080901033305 Minefield/3.1b1pre
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.