Closed Bug 510740 Opened 15 years ago Closed 15 years ago

[10.6] Gecko browsers lose focus on when Growl notification is dispatched (start in background without focus)

Categories

(Toolkit :: UI Widgets, defect, P2)

Product:
Toolkit
Component:
UI Widgets
Platform:
All
macOS
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9.3a1
Tracking Flags:
Tracking Status
status1.9.2 --- beta2-fixed
status1.9.1 --- ?

People

(Reporter: brndnsh, Assigned: smichaud)

References

Details

(Keywords: verified1.9.2, Whiteboard: [fixed by bug 522511][needs baking on trunk/1.9.2])

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6; en-us) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 Browsers which use Gecko launch without focus on OS X 10.6 (10A432). I can reproduce this with Camino (1.6.8, 2.0b3) and Firefox (3.5.2, 3.6a1, 3.7a1pre). Reproducible: Always Steps to Reproduce: 1. Open Camino or Firefox 2. The window does not appear in the foreground with focus 3. There is no step 3! :) Actual Results: The program launches, but the main window shows up behind other windows. Clicking the window then brings it into focus. Expected Results: When a program is launched, it should be immediately brought to the foreground and it should have focus. This was never an issue with previous versions of OS X.
--> Widget:Cocoa.
Component: General → Widget: Cocoa
QA Contact: general → cocoa
Thunderbird is also affected by this bug. I'm using 3.0b3, but it's probably safe to assume that older versions are affected as well.
Brandon: I don't see this using (10A421a), but I hope to be able to upgrade today to see if I can reproduce.
Summary: Gecko browsers launch without focus on OS X 10.6 → [10.6] Gecko browsers launch without focus on OS X 10.6
Using Build 10A432, I do see this happening, but not consistently. For example, I opened a Tweetdeck Window and then launched Firefox from the dock, and FF opened with the window behind the Tweetdeck window. But in other test I had Seamonkey open and then launched Firefox from the dock, and it brought the app to the foreground.
Status: UNCONFIRMED → NEW
Ever confirmed: true
In my tests, Firefox ALWAYS opens without focus and behind other windows. I tried it with Seamonkey open first, and I still got the same behavior. It should be noted that the latest trunk build of Seamonkey (2009-08-21) opens in the foreground with focus.
This no longer appears to be an issue in Minefield (build 20090823). I'm not sure when the behavior was corrected, because I don't use Minefield or Firefox consistently on OS X. This is still an issue with the Firefox 3.5 branch, Camino, and Thunderbird.
Adding smichaud to the cc list. Since SL is shipping on Friday, would be good to have someone take a look at this since 3.5.2 is affected. I can demo the issue on the machine in the lab.
Josh asked me to test Safari to see what happens with that app. Whenever I launch Safari with other apps open it launches in the foreground and takes focus. With Safari window open, I then launch Firefox and it opens in a window behind the Safari app.
Version: unspecified → 1.9.1 Branch
Brandon: Are you using the Profile Manager to launch Firefox?
I've never messed with the profile manager (or any profiles, for that manager) in Firefox. So no, I don't think I'm using the profile manager to launch Firefox. Is there something I should check, or is my ignorance a good enough answer?
I have tested it with Firefox 3.5.2 and OS X 10.6 (10A335f) and I cannot see this reported issue. Firefox always opens in the foreground.
smichaud and I are investigating this issue as we speak. The machine I am testing on had pave over installs of SL (versus erasing the disk and doing a clean install). Stay tuned for more info as we investigate.
Henrik: Did you do a clean install (erased the partition) when you installed that seed? (In reply to comment #11) > I have tested it with Firefox 3.5.2 and OS X 10.6 (10A335f) and I cannot see > this reported issue. Firefox always opens in the foreground.
Marcia just found that doing a clean re-install of the latest SnowLeopard seed (10A432) made the problem go away. (By clean install I mean booting from the SL install DVD, erasing the target partition, and only then installing to that target partition.) I'm not able to reproduce this bug on either of the SnowLeopard partitions on my MacBookPro (one being the 10A432 seed, the other being the old (May 2009) 10A354 seed) -- both of which were clean installs. Both machines that Marcia has been able to reproduce this bug on had "pave over" or update installs: On one several different previous versions of SnowLeopard had been installed via Software Update or DVD; on the other some version of Leopard had been "paved over" by the latest SnowLeopard seed (10432, installed via DVD). It's not yet clear what causes this problem. But it probably has something to do with what happens during an "unclean" update. And I'm pretty sure it's at least partly an Apple bug.
I tried "paving over" an OS X 10.5.7 partition with SnowLeopard seed 10A432 ... but this didn't cause the problem to start happening. So it probably won't be easy to find out what in the update process triggers this bug.
I should mention that both Marcia and I have been testing with FF 3.5.2.
The system I'm using was updated from OS X 10.5.7 to 10A432. I probably should've done a clean install, but naturally, I figured I would be too lazy to deal with all of the custom settings I would lose. Since most end-users are likely going to do upgrades rather than clean installs, this is definitely worth fixing (in my opinion). I don't know how relevant this is, but here's the output from Console.app when I launch Camino or Firefox 3.5.2: 24/8/09 20:53:21 [0x0-0x6ca6ca].org.mozilla.firefox objc[22055]: Class ABPreferencesModule is implemented in both /System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook and /Library/InputManagers/Safari AdBlock/Safari AdBlock.bundle/Contents/MacOS/Safari AdBlock. One of the two will be used. Which one is undefined. The latest Minefield doesn't seem to display anything in the console when it launches.
(In reply to comment #13) > Henrik: Did you do a clean install (erased the partition) when you installed > that seed? It's a half-way fresh install on an empty partition. Means I installed the seed prior to 10A335f and upgraded via software update to 10A335f.
Marcia just tested in a new account on a SnowLeopard partition where she can reproduce this bug -- the bug still happens in the new account. The bug also still happens with a new/clean Firefox profile. I'd guess some system dylib isn't getting updated that should be. I doubt we're going to be able to find the true cause of this problem except by accident. But the evidence keeps building that this is an Apple bug.
I do have the same problem. I have the final version of Snow Leopard and I did a clean install (erased the partition and installed SL from zero) on my Macbook Unibody (Late 2008). So it doesn't only appear if you updated the system.
I found what causes the bug at my system! It's growl!! if Growl is running, Firefox starts in the background (not focused), if Growl is deactivated, Firefox starts focused, the way it should be!
Well that's interesting... disabling Growl does seem to fix the problem. Camino and Firefox launch with focus when Growl is disabled.
yes it does... but disabling growl isnt really an option neither. unofortunately the new growl pre-beta doesn't fix the problem. i tried it on 3 different clean installed system, firefox always launchs with focus first but as soon as i install growl, focus is gone...
We don't do anything in the Growl framework that I'm aware of that would cause this. My guess is that it's specific to how the Firefox people came up with implementing Growl. Firefox folks made their own hook into Growl, didn't use the Growl.framework exactly how others would, so that may be worth looking at. Chris Growl Project Lead
(In reply to comment #25) > We don't do anything in the Growl framework that I'm aware of that would cause > this. My guess is that it's specific to how the Firefox people came up with > implementing Growl. Firefox folks made their own hook into Growl, didn't use > the Growl.framework exactly how others would, so that may be worth looking at. Although we are using the Growl framework source code unmodified (just not in framework form). Version 1.1.4
No other apps have complained about this yet on the Growl side, so I wonder if it's just specific to you guys.
(In reply to comment #25) > My guess is that it's specific to how the Firefox people came up with > implementing Growl. Firefox folks made their own hook into Growl, didn't use > the Growl.framework exactly how others would, so that may be worth looking at. What about Camino's use of it?
Isn't Camino very similar to Firefox? Well all my other apps which use Growl (Adium, Skype, Mail, Toast) don't have the problem with the "focus", so I guess it is a special problem of Firefox in combination with Growl. I hope this can be fixed soon, since I really need Growl and I dont wanna use another browser than Firefox. :-)
That question was directed more at Chris Forsythe and fellow Camino devs; I didn't think we had done anything non-standard, so the theory put forth in comment 25 may be incorrect if Camino suffers from this bug as well.
Oh okey, I'm sorry. :-) I posted it on the macrumors forum and it looks like it's a general bug that affects (very likely) everybody. http://forums.macrumors.com/showthread.php?t=775500
We just use the Growl.framework (1.1.5) in Camino. We build it ourselves, but using the Growl Xcode project and the Growl source files, so that shouldn't be significantly different from dropping in the pre-built binary framework. Otherwise, we should hook up to Growl like any other Cocoa app, I believe.
Summary: [10.6] Gecko browsers launch without focus on OS X 10.6 → [10.6] Gecko browsers launch without focus on OS X 10.6 with Growl installed
Are there any potential workarounds for this? I tried disabling Growl for Camino in the Growl prefpane, but as long as Growl is still running, the bug persists.
Interestingly, the patch for bug 506470 also "fixes" this bug (on trunk/mozilla-central) ... or at least works around it.
Depends on: 506470
By the way, I *don't* see this problem in Camino (1.6.8 or 2009-08-28's 1.9.0-branch nightlies). I only see it in FF 3.0.X and 3.5.X. It started happening with the 2007-05-03-04-trunk nightly (probably as a consequence of the patch for bug 378785).
I should also mention that I tested with Growl 1.1.6 on the 10A432 seed of SnowLeopard (OS X 10.6).
(In reply to comment #35) > By the way, I *don't* see this problem in Camino (1.6.8 or > 2009-08-28's 1.9.0-branch nightlies). Someone mentioned the issue with the Camino 0828/gecko 1.9.0 build in the forums. Not yet sure if Growl is installed. http://forums.mozillazine.org/viewtopic.php?p=7394775#p7394775
We've checked in a fix for this in Camino; it should be in tomorrow's 2.0b4pre nightly: http://caminobrowser.org/contribute/#nightly Thanks to the Growl devs for their help.
No longer depends on: 506470
This is definitely fixed in the latest Camino nightly (2009-09-01), thanks so much!
Yes, also here it's fixed with Camino!! Thank you so much for all your affords, guys!! I hope Firefox will get the fix soon too, since there's a solution out now! :-)
> We've checked in a fix for this in Camino; And the bug number is?
Apparently there *isn't* a bug number. But the (Camino-specific) patch was landed last night at 2009-08-31 21:02 PDT: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2009-08-31+21%3A02%3A00&maxdate=2009-08-31+21%3A02%3A00&cvsroot=%2Fcvsroot This patch lazily loads Growl (in Camino). So does the patch for bug 506470 (in Firefox). So Firefox (along with Seamonkey) still does need the patch for bug 506470 to fix this bug.
Depends on: 506470
Component: Widget: Cocoa → XUL Widgets
Product: Core → Toolkit
QA Contact: cocoa → xul.widgets
Version: 1.9.1 Branch → unspecified
Hardware: x86 → All
Don't forget that Thunderbird also needs a patch for this.
Landing the patch for bug 506470 on the 1.9.1 branch should fix FF 3.5.X and "comm-central" Thunderbird. Current "comm-central-trunk" Thunderbird nightlies should already be fixed -- please try one out. The patch for bug 506470 will need to be landed on the 1.9.0 branch to fix FF 3.0.X.
"comm-central" -> "comm-1.9.1"
For what it's worth, this bug is triggered by the following "system call" in Growl code (in the [GrowlApplicationBridge _launchGrowlIfInstalledWithRegistrationDictionary:] method): status = LSOpenFromRefSpec(&spec, NULL); I tried several changes to the spec.launchFlags parameters -- all to no effect. I don't see anything wrong with this call. And the fact that the bug only happens on 10.6 seems to indicate that this is an Apple bug. Good that we have a decent workaround.
Fixed (on the trunk) by the patch for bug 506470. Approval is being sought to land that patch on the 1.9.2 and 1.9.1 branches. Then, if all goes well, we can try to get it landed on the 1.9.0 branch.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
I'm sorry to bother you guys again, but what exactely does it mean with the patchs for 1.9.2, 1.9.1 and 1.9.0? Could you fix the problem with the foucs on Firefox (it seems to be fixed on Camino)? When will the updated be online? Thanks!
Firefox 3.0.X is on the 1.9.0 branch. Firefox 3.5.X and "comm-1.9.1" Thunderbird are on the 1.9.1 branch. What will become Firefox 3.6 is on the 1.9.2 branch. Yes, it's confusing. It sometimes helps to look at the names of downloads available at ftp://ftp.mozilla.org/pub/mozilla.org/.
Bug still exists with Firefox 3.5.3
(In reply to comment #50) > Bug still exists with Firefox 3.5.3 Yes. This bug depends on bug 506470. A fix for that bug did not land in time for Firefox 3.5.3. It should be fixed in Firefox 3.5.4.
So, bug 515396 seems to indicate that we just moved this problem to the first time we use growl so it still exists. Bug 506470 just moved the problem and did not fix it.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
What I say in comment #46 suggests this is an Apple bug (introduced in 10.6). If so, I'm not sure there's anything we can do about it.
(In reply to comment #54) > What I say in comment #46 suggests this is an Apple bug (introduced in 10.6). > > If so, I'm not sure there's anything we can do about it. Has someone at least filed a radar request with them?
> Has someone at least filed a radar request with them? Not yet. I've asked at bug 515396 if the problem also happens in other browsers (like Safari), and if the update to 10.6.1 fixed it. Do you know the answer to either of these questions?
Interestingly, the Growl home page (http://growl.info/) says the following: For 10.6 Snow Leopard, do not install 1.1.6. We are working on Growl 1.2 for 10.6 Snow Leopard I'm going to put this bug aside until Growl 1.2 is available.
(In reply to comment #57) > Interestingly, the Growl home page (http://growl.info/) says the > following: > > For 10.6 Snow Leopard, do not install 1.1.6. We are working on Growl > 1.2 for 10.6 Snow Leopard > > I'm going to put this bug aside until Growl 1.2 is available. You can grab the beta of 1.2 on our beta page: http://growl.info/beta.html Do *not* use 1.1.anything on 10.6.anything.
I've installed Growl 1.2b3 on OS X 10.6.1, and this bug still happens with FF 3.5.3 (which doesn't yet have the patch for bug 506470). So presumably bug 515396 would also still happen. This doesn't really surprise me -- the crucial factor seems to be what the Growl code bundled with FF (or Camino) does. Chris, can you (or some other Growl developer) address what I say in comment #46? Is that problem something you're working on? Do you agree that it's an Apple bug? Do you think you can fix it or work around it?
You guys are the only one seeing this problem, to me just simply saying "hey it's an apple bug because it's a new os!" sounds knee jerk to me. We have over 200 applications using the Growl framework, and you guys are the only one having this problem. You also have multiple tickets open on the same problem for multiple products (I wonder if tbird has this problem too?), it might be worth looking at both tickets. The other ticket is bug #515396.
> to me just simply saying "hey it's an apple bug because it's a new > os!" sounds knee jerk to me. No, it's not. That something only happens on a particular OS version often *is* a sign that it's an OS bug. What I'd appreciate from you is some help trying to resolve this. One reason this doesn't happen with other apps could be that the initialization code (the code that ends up calling LSOpenFromRefSpec()) doesn't get called while any app window has the focus. But this is a pain to investigate, because I don't know when a particular app runs the initialization code. Yes, if an app that bundles Growl is open source, I can look through its code to find out. But there are many apps, and I don't know where to start. Do you know of any other apps that bundle Growl and "lazily" initialize it (for example on receiving the first Growl notification, as trunk-FF now does)? I can try to send them notifications while one of their windows has the focus, and see what happens. If the problem happens I can tell you about it. If it doesn't happen I can look through the app's source code to try to find out why not. I currently plan to use your growlnotify commandline utility to send the notifications. To avoid giving Terminal the focus when I do this, I'll ssh in to the machine I'm testing on. Do you think this sounds reasonable?
I know of no other applications that do not use our framework as we recommend it. I'm a project manager, so you'll have to explain to me what exactly you are looking for, or look at the code yourself. Our documentation on how to implement the framework is on our website, along with our framework being open source and freely available to look at, should be beneficial here. We provide as much help as we can, your implementation of the bindings to talk to Growl was even developed in our source tree so that it wouldn't be messy for you guys. However we're at max for our current resources to be able to assist you other than to comment. We only have 2 active, and 1 nonactive but working on features, developers. The 2 active developers *must* work on the 1.2 release before working on another else, as that's our current priority. I can direct specific questions to them though if you would think that is helpful. http://code.google.com/p/growl/issues/detail?id=15 may be related to this, but I don't know for sure. What might be beneficial to you is to take the code you guys use to talk to Growl, and put it into a testing application. In a copy of the same application, use our shipping framework. If your code does it and ours does not, then you have a likely point to start investigating. Shawn however says that the code he used isn't that modified from what we have. You can look here for the steps he took: http://code.google.com/p/growl/source/list?start_rev=e5a110c5e010f4ab756079bc648b635393809d3c should be all of the relevant changes he made. Hope this helps, let me know what I can do.
Thanks very much, Chris, for this info. I'll work my way through it. But right now my most urgent question is (I think) a very simple one -- I need a good way to send notifications that doesn't interfere with app focus or window focus. I'd planned to use growlnotify (sshed in to the machine I'm testing on). But just now I found that, using it, I can't reproduce bug 515396 in today's Minefield nightly. Do you have any suggestions?
(In reply to comment #63) > But right now my most urgent question is (I think) a very simple one -- I need > a good way to send notifications that doesn't interfere with app focus or > window focus. I'd planned to use growlnotify (sshed in to the machine I'm > testing on). But just now I found that, using it, I can't reproduce bug 515396 > in today's Minefield nightly. Why not just make a quick test app that sets up a timer; then when that timer fires, send a Growl event?
We have an application called BeepHammer in our sdk that will send a large amount of notifications to Growl in a very short amount of time (hence the name). That may be helpful. It requires gui interaction. I agree with Ilya, you may want to make a quick test app if you're going to need a shell to run it. A cocoa app using our built framework would be a good way to get it working easily, then you could take the code you guys use and put it into the tester app to see if you have the same issue.
It sounds like growlnotify already does everything I need. And using it is of course much simpler than any of your suggestions. As best I can tell, I just need to send *one* notification on demand, without interfering with app or window focus. Using growlnotify while sshed-in seems ideal for this purpose. Do you have any idea why it doesn't appear to be "working"? Or is it just that this bug is more complex than it first appears?
> this bug Bug 515396.
> http://code.google.com/p/growl/issues/detail?id=15 This does look very helpful. Thanks.
(In reply to comment #68) > > http://code.google.com/p/growl/issues/detail?id=15 > > This does look very helpful. Thanks. oh bah - rudy had talked to me over im about this very issue and I forgot to post it in the bug here (had to catch a train). Sorry!
Oh, are you ssh'd into the mac but not logged in via the gui? Because I don't think that's going to work.
In all my questions about growlnotify (and about sending Growl notifications *to* Firefox), I was barking up the wrong tree. See bug 515396 comment #12.
We put out beta 5 of Growl with some changes to our framework that might address this. The revisions are linked. You guys may want to check it out. http://growl.info/beta.html
It still happens with the just released Growl 1.2, FF 3.5.3 and OS X 10.6.1
And did you update the framework in firefox to the 1.2 framework code? That's where the changes were made to address this for Growl, not in Growl 1.2 itself. At least, I'm assuming they'll fix it. GrowlSafari had it intermittently until we made those changes.
We have not upgraded the code for the framework, but we should!
Status: REOPENED → NEW
Flags: blocking1.9.2?
Priority: -- → P2
Summary: [10.6] Gecko browsers launch without focus on OS X 10.6 with Growl installed → [10.6] Gecko browsers lose focus on when Growl notification is dispatched
Flags: blocking1.9.2? → blocking1.9.2+
Interesting, I just installed Flock and it doesn't have this problem at all (version 2.0.3)
I've finally got time to get back to this. > And did you update the framework in firefox to the 1.2 framework > code? I'd like to try this ... but it's not at all clear how to do so. I've downloaded the Growl 1.2 source distro from http://growl.googlecode.com/files/Growl-1.2-src.tbz. I've also found what appears to be a current, browseable hg repository at http://code.google.com/p/growl/source/browse/. But (as far as I can tell) nothing there corresponds exactly to what's in the Mozilla tree, at toolkit/components/alert/src/mac/growl. > Shawn however says that the code he used isn't that modified from > what we have. You can look here for the steps he took: > http://code.google.com/p/growl/source/list?start_rev=e5a110c5e010f4ab756079bc648b635393809d3c > should be all of the relevant changes he made. This appears to correspond to the moz-extension branch in your browseable hg repository (http://code.google.com/p/growl/source/browse/?r=e5a110c5e010f4ab756079bc648b635393809d3c#hg%3Fstate%3Dclosed). But (like I said) it doesn't correspond exactly with what's in the Mozilla tree. Furthermore, everything in the moz-extension branch appears to be quite old -- older than Growl 1.2. Any ideas? I'd particularly like to hear from Shawn, who appears to be responsible for what's in the Mozilla tree (at toolkit/components/alert/src/mac/growl).
I basically took the framework files that we needed, and dumped them in our tree. I think Dave actually upgraded us last time though.
Yeah it was last updated in bug 421551 to 1.1.4 and I recall there was something odd about upgrading but apparently I failed to note at the time exactly what I did
Thanks, sdwilsh and dtownsend. You guys winged it. So did I, and that works. It also fixes this bug! I've got a patch at bug 522511 that updates the bundled Growl files' version from 1.1.4 to 1.2. A tryserver build should appear there in an hour or so. Those who want to should test with the STR from bug 515396 comment #12.
Maybe it might be worth adding a README to our source explaining how to go about upgrading this?
I personally think my comments at bug 522511 are documentation enough. hg blame should be enough to find them.
Depends on: 522511
This should be fixed (on the trunk) by the patch for bug 522511.
Status: NEW → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
assigning to Steven, since he's owner of bug 522511.
Assignee: nobody → smichaud
Whiteboard: [fixed by bug 522511]
Marking fixed since bug 522511 is fixed.
status1.9.2: --- → final-fixed
I just intalled Firefox 3.5.4 Bug is still there, no focus at startup!
The patch on bug 522511 hasn't been landed for Firefox 3.5.x yet. Steven, do we plan to backport it for 1.9.1?
> Steven, do we plan to backport it for 1.9.1? I'd like to, but I'm not sure others will agree. This bug isn't really a security or stability issue, and those are normally the criteria for deciding whether a patch should land on one of the "stable" branches (currently the 1.9.1 (e.g. FF 3.5.X) and 1.9.0 (e.g. FF 3.0.X) branches). In any case, I'd like to have the patch for bug 522511 bake on the trunk and 1.9.2 branch (aka FF 3.6) for quite a bit longer before even trying to get approval.
Can we get this patch on 1.9.1 too? I know that is no security or stability issue but with the current behavior under 10.6 the browser window will always open in the background and our Mozmill tests fail because we need the window in the foreground. (In reply to comment #88) > In any case, I'd like to have the patch for bug 522511 bake on the > trunk and 1.9.2 branch (aka FF 3.6) for quite a bit longer before even > trying to get approval. Let's ask if it is wanted on 1.9.1. It can bake in parallel.
status1.9.1: --- → .2-fixed
Whiteboard: [fixed by bug 522511] → [fixed by bug 522511][needs baking on trunk/1.9.2]
Target Milestone: --- → mozilla1.9.3a1
I don't think you meant to mark this bug as fixed in 1.9.1.2.
status1.9.1: .2-fixed → ---
No, I wanted to ask for the status. Let's do it now. Sorry.
status1.9.1: --- → ?
Verified fixed on trunk and 1.9.2 with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20091102 Minefield/3.7a1pre ID:20091102034445 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b2pre) Gecko/20091101 Namoroka/3.6b2pre ID:20091101033813
Status: RESOLVED → VERIFIED
Keywords: verified1.9.2
Summary: [10.6] Gecko browsers lose focus on when Growl notification is dispatched → [10.6] Gecko browsers lose focus on when Growl notification is dispatched (start in background without focus)
Version: unspecified → Trunk
fyi, a 1.9.1 backport would be very useful for TB3
(In reply to comment #94) See comment #88 above. But this has been on the trunk and 1.9.2 branch for a couple of months now, with no reported problems. Why don't you ask for 1.9.1-branch approval for my patch for bug 522511?
You need to log in before you can comment on or make changes to this bug.